[Twisted-Python] First pre-release of Twisted 11.1.0
Hello, fine people of the intraweb, We're dangerously approaching the end of the year, without a second release done, which is obviously unacceptable. I thus present you with Twisted 11.1.0pre1: http://people.canonical.com/~therve/Twisted/11.1.0pre1/ Some hightlights of the 178 tickets closed: * The poll reactor as default where applicable, instead of select everywhere. * A new SSL implementation only relying on OpenSSL for cryptography, (not I/O) making it more robust, and adding IOCP support in the process. * Several improvements to the fresh HTTP/1.1 client implementation, including proxy and cookie support. * My personal favorite: a new howto has been published on test-driven development with Twisted. * A special mention to the new abortConnection support on TCP and SSL connections, heroically pushed by Itamar and Jean-Paul, and the oldest ticket closed by this release. Please give it all the testing love it deserves (and be harsh if necessary). Release-manager-ly yours, -- Thomas
On Oct 21, 2011, at 10:28 AM, Thomas Hervé wrote:
After doing some testing of my own, I am discovering that there may be some issues with the prerelease in this area. I'm getting this traceback when running Calendar Server under a load simulator: Unhandled Error Traceback (most recent call last): File ".../twisted/python/log.py", line 84, in callWithLogger return callWithContext({"system": lp}, func, *args, **kw) File ".../twisted/python/log.py", line 69, in callWithContext return context.call({ILogContext: newCtx}, func, *args, **kw) File ".../twisted/python/context.py", line 118, in callWithContext return self.currentContext().callWithContext(ctx, func, *args, **kw) File ".../twisted/python/context.py", line 81, in callWithContext return func(*args,**kw) --- <exception caught here> --- File ".../twisted/internet/selectreactor.py", line 150, in _doReadOrWrite why = getattr(selectable, method)() File ".../twisted/internet/tcp.py", line 199, in doRead rval = self.protocol.dataReceived(data) File ".../twisted/protocols/tls.py", line 413, in dataReceived self._flushReceiveBIO() File ".../twisted/protocols/tls.py", line 360, in _flushReceiveBIO self._shutdownTLS() File ".../twisted/protocols/tls.py", line 427, in _shutdownTLS self.transport.loseConnection() File ".../twisted/internet/_newtls.py", line 71, in loseConnection return self._base.loseConnection(self._connection, reason) File ".../twisted/internet/abstract.py", line 360, in loseConnection self.connectionLost(_connDone) File ".../twisted/internet/tcp.py", line 272, in connectionLost self._closeSocket(not reason.check(error.ConnectionAborted)) exceptions.AttributeError: 'NoneType' object has no attribute 'check' Note that none of my application code is showing up on the stack: just Twisted, which makes me think that this is a bug that _could_ be reproduced without a big application :). Does anyone have an idea what this could be? I will file a ticket soon but I'd love to have some reproduction instructions... This definitely doesn't happen under 11.0, so it is a new problem in trunk/11.1. -glyph
On Wed, 2011-10-26 at 07:09 -0400, Glyph wrote:
Does anyone have an idea what this could be? I will file a ticket soon but I'd love to have some reproduction instructions...
It seems to be just a normal TLS shutdown, the second stage after a TLS-level disconnect has been both sent and received... but then for some reason the code thinks we did a TCP half-close too. Are you doing loseWriteConnection in your code? Changing _newtls._BypassTransport.loseConnection so it has reason=ConnectionDone() as a default (or maybe a Failure wrapping ConnectionDone) rather than None would fix the symptom, but possibly that's the wrong thing to do.
On Wed, 2011-10-26 at 07:09 -0400, Glyph wrote:
I opened a ticket: http://twistedmatrix.com/trac/ticket/5341 I've proven to myself that half-close is broken, but I still haven't managed to actually reproduce this problem. Reading the code it is clear it can only happen in half-close code paths, though.
On Oct 21, 2011, at 10:28 AM, Thomas Hervé wrote:
After doing some testing of my own, I am discovering that there may be some issues with the prerelease in this area. I'm getting this traceback when running Calendar Server under a load simulator: Unhandled Error Traceback (most recent call last): File ".../twisted/python/log.py", line 84, in callWithLogger return callWithContext({"system": lp}, func, *args, **kw) File ".../twisted/python/log.py", line 69, in callWithContext return context.call({ILogContext: newCtx}, func, *args, **kw) File ".../twisted/python/context.py", line 118, in callWithContext return self.currentContext().callWithContext(ctx, func, *args, **kw) File ".../twisted/python/context.py", line 81, in callWithContext return func(*args,**kw) --- <exception caught here> --- File ".../twisted/internet/selectreactor.py", line 150, in _doReadOrWrite why = getattr(selectable, method)() File ".../twisted/internet/tcp.py", line 199, in doRead rval = self.protocol.dataReceived(data) File ".../twisted/protocols/tls.py", line 413, in dataReceived self._flushReceiveBIO() File ".../twisted/protocols/tls.py", line 360, in _flushReceiveBIO self._shutdownTLS() File ".../twisted/protocols/tls.py", line 427, in _shutdownTLS self.transport.loseConnection() File ".../twisted/internet/_newtls.py", line 71, in loseConnection return self._base.loseConnection(self._connection, reason) File ".../twisted/internet/abstract.py", line 360, in loseConnection self.connectionLost(_connDone) File ".../twisted/internet/tcp.py", line 272, in connectionLost self._closeSocket(not reason.check(error.ConnectionAborted)) exceptions.AttributeError: 'NoneType' object has no attribute 'check' Note that none of my application code is showing up on the stack: just Twisted, which makes me think that this is a bug that _could_ be reproduced without a big application :). Does anyone have an idea what this could be? I will file a ticket soon but I'd love to have some reproduction instructions... This definitely doesn't happen under 11.0, so it is a new problem in trunk/11.1. -glyph
On Wed, 2011-10-26 at 07:09 -0400, Glyph wrote:
Does anyone have an idea what this could be? I will file a ticket soon but I'd love to have some reproduction instructions...
It seems to be just a normal TLS shutdown, the second stage after a TLS-level disconnect has been both sent and received... but then for some reason the code thinks we did a TCP half-close too. Are you doing loseWriteConnection in your code? Changing _newtls._BypassTransport.loseConnection so it has reason=ConnectionDone() as a default (or maybe a Failure wrapping ConnectionDone) rather than None would fix the symptom, but possibly that's the wrong thing to do.
On Wed, 2011-10-26 at 07:09 -0400, Glyph wrote:
I opened a ticket: http://twistedmatrix.com/trac/ticket/5341 I've proven to myself that half-close is broken, but I still haven't managed to actually reproduce this problem. Reading the code it is clear it can only happen in half-close code paths, though.
participants (4)
-
Glyph -
Itamar Turner-Trauring -
Jonathan Lange -
Thomas Hervé