Socket errors when using WSS about sockjs-tornado

[mrjoes]

All of them are Tornado related.

First one is weird, looks like SSL bug: self.socket is None if stream is disconnected. And it tried to read from disconnected stream.

Next three are related, client drops connection before it was properly established or before it was properly closed.

If connection was not established properly, you don't care about it - it might be caused by clients behind restrictive proxies, etc. But it should not spam the log, agree here.

Also, if connectio is closing in safe_finish (last entry), it is not a problem as well. Though, should not be logged.

I'll CC @bdarnell, maybe he will have some additional feedback.

[bdarnell]

I don't have much to add here other than that these kinds of issues are certainly possible given the way callbacks are run asynchronously (i.e. the socket object becomes None before the close callback is run). I'm not sure whether to consider these problems in the framework or in the application code (and if the latter, how to make them less likely).

[mrjoes]

I'm fine if application can handle these kind of exceptions and suppress them.

In stack traces above there's no sockjs-tornado code (well, there is, but it is just slightly customized version of tornado.websocket module). I guess I can wrap most of the networking code with try/except, which should suppress such exceptions.

[aychedee]

Okay, thanks very much for the information. And the fantastic projects as well!

[hjwp]

Any thoughts on what the first line in each traceback means?

2012-05-15 00:59:18,052 WARNING:Write error on 191: [Errno 14] Bad address

and

2012-05-15 01:03:53,559 WARNING:Write error on 3: [Errno 32] Broken pipe

I think they are the root causes of the problem, and the tracebacks are just the visible effect of tornado picking up on something being broken... but what is causing these problems in the first place?