On Fri, Aug 22, 2008 at 7:51 PM, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > > 2008/8/22 Nimrod A. Abing <[EMAIL PROTECTED]>: >> >> On Fri, Aug 22, 2008 at 2:43 PM, Graham Dumpleton >> <[EMAIL PROTECTED]> wrote: >>> >>> Details can be found at: >>> >>> http://code.google.com/p/modwsgi/wiki/ChangesInVersion0105 >>> http://code.google.com/p/modwsgi/wiki/ChangesInVersion0202 >>> >>> Important changes are file descriptor leaks on a graceful restart in >>> both versions and for version 2.2 possible truncation of data when >>> using wsgi.file_wrapper. An upgrade would be recommended especially >>> due to the latter if using wsgi.file_wrapper in a way or on system >>> affected by the problem. >> >> Thanks for the fix for wsgi.file_wrapper. We had been experiencing >> problems lately with users uploading large files. All tracebacks seem >> to point to something in wsgi.file_wrapper. Unfortunately it is one of >> those "heisenbugs". Some random thing/file upload triggers it, it >> disappears when you try to debug it and it's impossible to recreate. > > You mean downloading don't you? At least I take uploading to mean > putting a file on server, not the other way around, so wouldn't expect > wsgi.file_wrapper to be involved. I would also have expected you to be > using Apache 2.2 on UNIX where for static file downloads wouldn't be > an issue.
Uploading usually. But I have reason to suspect that it's happening because users abort the upload. But we also get weird tracebacks from time to time, these involved URL's where nothing is POSTed. We are currently using Apache 2.0. We use lighttpd for static content. > Maybe you want to better explain the problem you are seeing in case it > is something completely different. One concern would be that if it is > a large file upload that takes more than 5 seconds, that if you are > using daemon mode and recycling process based on number of requests, > that upload is being interrupted when process is recycled, as by > default will only allow at most 5 seconds for process to restart > before killing it. In other words, it is not a graceful restart where > process persists until all active requests complete. We are using daemon mode. It's interesting that you brought that up. It had never occurred to me that the daemon could timeout in the middle of a POST request, in any case I would not expect it to timeout in the middle of *any* request. Like I said above, it happens more often on uploads. I suspect that these users are using dial-up, a lot of the IPs are from Cox address block. What are the defaults for the *-timeout options if you do not supply them? > Thus, long running file uploads perhaps better handled in embedded > mode, or delegate the URLs for file upload to special daemon process > that doesn't recycle process so as to avoid problem with it being > interrupted. That would require us to have a subdomain just for this purpose, I'm predicting this will cause the Django authentication system to fail somehow. But I will look into it and see if it's feasible. -- Best Regards, Nimrod A. Abing W http://arsenic.ph/ W http://preownedcar.com/ W http://preownedbike.com/ W http://abing.gotdns.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" 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/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
