On Fri, Nov 14, 2003 at 05:45:52AM +1000, Sam Jordan wrote:

Hi,

I noted the following exception while running some msn related code earlier:

2003/11/14 05:09 EST [PassportLogin,client] Traceback (most recent call last): File "/home/sam/Twisted/twisted/python/log.py", line 65, in callWithLogger callWithContext({"system": lp}, func, *args, **kw) File "/home/sam/Twisted/twisted/python/log.py", line 52, in callWithContext return context.call({ILogContext: newCtx}, func, *args, **kw) File "/home/sam/Twisted/twisted/python/context.py", line 32, in callWithContext return func(*args,**kw) File "/home/sam/Twisted/twisted/internet/default.py", line 513, in _doReadOrWrite why = getattr(selectable, method)() --- <exception caught here> --- File "/home/sam/Twisted/twisted/internet/tcp.py", line 98, in doRead return Connection.doRead(self) File "/home/sam/Twisted/twisted/internet/tcp.py", line 234, in doRead data = self.socket.recv(self.bufferSize) SSL.SysCallError: (104, 'Connection reset by peer')

On closer inspection it seems that the surrounding try/except clause only cares about SSL.SysCallErrors which pertain to unexpected EOF and all others are re-raised. The only reason I can come up with for why this is the case is that it was not anticipated that other exceptions (like the one above) could arise from the given recv call. I would expect that in the above instance, connectionLost should be called, but it may very well be that i'm missing some subtlety so I am yet to submit a bug report.

In tcp.py, on line 114, this exception is being caught and logged, then CONNECTION_LOST is being returned, which should cause all the appropriate lost-connection-callbacks to be invoked. The error is logged just to err on the side of being overly informative. It shouldn't interfere with connectionLost or clientConnectionLost. If it is, please do file a bug report. Jp