Geek Answers Handbook

How to prevent "IOError: Failed to write data" when the client closes the connection to the Django / WSGI application?

I have an application for iPhone that uses web services implemented in Python using Django and Piston running on apache server via WSGI.

Sometimes the application closes its connection to the server until the call ends. When he does this, he calls:

[Tue Sep 06 11:29:46 2011] [error] [client 207.35.164.99] mod_wsgi (pid=820): Exception occurred processing WSGI script 'myscript.wsgi'. [Tue Sep 06 11:29:46 2011] [error] [client 207.35.164.99] IOError: failed to write data

appears in the server error logs.

I can "fix" the problem in the application without closing the explicit connection closure, but leaving it to finish loading and ignore the result. However, I would like to fix this on the server side, if possible. How can i do this?

+4
source share
2 answers

[disclaimer: this is an explanation of “why this is not easy to do,” not a decision]

As @Slott pointed out, this is certainly technically correct behavior when stream.close or stream.write is called on a private socket. However, I understand the motivation for the question ... in the context of the wsgi application, clients terminating the connection after full or partial reading are not "exceptional" behavior, this happens all the time. In order for it to remain unprocessed, it seems that it was unexpected / the code for this was not prepared when, in fact, it was expected, and it is not worth marking it. Therefore, it would be nice to fix it.

The trick is that you need to find a way to distinguish cases ...

  • Situations such as “client read” Status: 304 ', and then a closed connection “or” the client reads all bytes, and then a closed connection, even if it requested a connection, should be reused “- these are the ones in which it would be so as not to produce any entries other than calling log.debug() .

  • But situations like “the client stopped reading in the middle of the file because the connection worked when the ISP router had a move” deserve an error that is logged. Something could not be completed successfully, and any transactional state of your application server will be canceled. In this case, an IOError propagating upwards is the right thing.

Such errors are only silent, if at every place they can be raised, the code is changed to distinguish these two cases. Until then, wsgi authors seemed to be mistaken on the side of caution. Therefore, I do not know how to do this.

(In addition, I should note that this is not dependent on Django, I use paste + pylons and have the same thing)

+6
source

See this: http://code.google.com/p/modwsgi/issues/detail?id=29

If the processing is repeated, then the message registers the debug level and there is no Python exception. Thus, in order to see problems with the client’s closed connection when using iteration, you need to debug LogLevel.

Apparently you will need to configure the Django response as iterable instead of a string.

+1
source

More articles:


All Articles