Graham, thanks for the information! I know very, very little about mod_wsgi, but would it be possible to pull the request content out of the socket and store it somewhere else every time? It seems like the bug only gets us when we don't do something with all the request data. Why not automatically pull all the request data from the socket before sending a response, or even before calling the wsgi app? Again, I don't know much about this, and I might be suggesting something really dumb.
Alex On Tue, Apr 27, 2010 at 5:39 AM, Graham Dumpleton <[email protected]> wrote: > > > On Apr 27, 2:51 am, Christoph Schindler <[email protected]> wrote: >> Hi! >> >> Posting the confirm/ form takes exactly 5 minutes in my Satchmo >> installation. The following redirect to success/ takes a fraction of a >> second. >> >> This happens with the test module as well as the COD module. >> >> The log entry ("Processing COD Payment transaction...") happens >> immediately. >> >> I have _no_ idea where to start looking into this. Any hints would be >> greatly appreciated! > > Are you using mod_wsgi daemon mode? Are you running on MacOS X? > > What do you get on that system when you run: > > >>> import socket > >>> s = socket.socket(socket.AF_UNIX) > >>> s.getsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF) > 8192 > > If you get a low value like 8192 instead of a value in the range of a > megabyte, use the receive-buffer-size and send-buffer-size options to > WSGIDaemonProcess as documented in: > > http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess > > to increase the buffer sizes of the UNIX socket used to communicate > with mod_wsgi daemon processes. > > It is a known issue that some operating systems have ridiculously low > buffer sizes for UNIX sockets. This contributes to potentially for > process deadlock when a WSGI application doesn't ensure it consumes > any request content prior to returning a response and both request > content and response content are greater than that buffer size in > length. > > This particular problem can manifest all sorts of hosting situations > that use proxying in one form or another a pretty well all systems try > and send all request content across proxy connection before reading > response. Thus is request content not consumed it could be in a > blocked state and not ready to read response when it is sent. > > Many systems use INET sockets which have much larger buffer sizes > anyway. UNIX sockets on some systems just have insane buffer sizes. > > Even if mod_wsgi was changed to somehow avoid this issue, you could > still encounter it on other systems. The mod_wsgi code could perhaps > at least look at what socket buffer sizes are and increase them to > some large value when too low rather than expect user to use those > options to do so. > > Graham > > -- > You received this message because you are subscribed to the Google Groups > "Satchmo users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/satchmo-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Satchmo users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=en.
