On Jan 5, 8:33 pm, ppdo <ppdo2...@yahoo.com> wrote:
> The failure does not depend on the file size: I manage to upload files
> bigger than 60 MB and fail on 30 kB files.
>
> I tried with Safari and Firefox and I got the same results, though I
> got the *impression* (but given the randomness of the problem I am not
> sure this is a real observation) that it fails more often if I use the
> client on the same machine as the server and less if the client runs
> from a different machine. Both client and server were all OSX/Leopard.
>
> In the Apache configuration there is no explicit timeout directive.
> However, when the problem occurs the client hangs for a very long time
> before reporting the error: from the server logs it takes about 5
> minutes. When it succeeds the operation completes within a few
> seconds, depending on the size of the file.

The default for Timeout if not set is 300 seconds (5 minutes).

>From Apache documentation:

"""The TimeOut directive currently defines the amount of time Apache
will wait for three things:

The total amount of time it takes to receive a GET request.
The amount of time between receipt of TCP packets on a POST or PUT
request.
The amount of time between ACKs on transmissions of TCP packets in
responses."""

The timeout is significant here as the error in logs for mod_wsgi
(which is more informative than mod_python and why I asked about it)
was:

[Mon Jan 05 08:13:06 2009] [error] [client 127.0.0.1] (70007)The
timeout specified has expired: mod_wsgi (pid=46687): Unable to get
bucket brigade for request., referer: http://127.0.0.1/myapp/upload/2009-01-03/1

So, what would appear to be happening is that at the client socket
itself where Apache is applying this timeout, one of those three
events is occurring.

The first actually probably applies to POST request as well. What it
actually means is how long it takes to read the headers of HTTP
request. If the client is very slow providing the full headers it
would timeout. It can't be that in this case though as the higher
mod_wsgi code would never have been called in the first place if the
full request headers hadn't been read.

The others are more serious lower level socket network issues.

I can't think of any other reason that this timeout would be triggered
within Apache at a higher level than the client socket.

All I can probably suggest at this point is use tcpdump to monitor the
traffic to port 80 for some of these requests and see if you can
capture what is occurring at network layer for socket when it hangs.
>From that might at least confirm if data is getting to Apache. If you
know enough about networking, maybe you can tell if all the correct
protocol level messages for TCP are there.

Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to