On May 1, 12:02 am, Alex Robbins <[email protected]> wrote: > 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.
The mod_wsgi layer cannot do that as it is quite valid for a WSGI application to return the start of a response and then only start consuming the input. Thus if it was automatically discarded, it would cause WSGI applications to fail which worked like that. Graham > 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#WSGIDae... > > > 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 > > athttp://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 > athttp://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.
