On Nov 6, 2011, at 3:42 AM, fox wrote: > we're developing a web2py application over a non reliable network > connection and we encountered some problems with file uploading that > made us going crazy. > We had the same error as: > http://markmail.org/message/vtduef55vy43zqsv#query:web2py%20socket%20timeout+page:1+mid:mhacsuphhsdxt43h+state:results > or > http://comments.gmane.org/gmane.comp.python.web2py/70636 > > The problem was always: > Traceback (most recent call last): > File "/srv/web2py/gluon/main.py", line 442, in wsgibase > parse_get_post_vars(request, environ) > File "/srv/web2py/gluon/main.py", line 276, in parse_get_post_vars > request.body = copystream_progress(request) ### stores request > body > File "/srv/web2py/gluon/main.py", line 144, in copystream_progress > copystream(source, dest, size, chunk_size) > File "/srv/web2py/gluon/fileutils.py", line 366, in copystream > data = src.read(chunk_size) > File "/usr/lib/python2.6/socket.py", line 377, in read > data = self._sock.recv(left) > timeout: timed out > > We found out that tuning rocket setting SOCKET_TIMEOUT made everything > work. We changed that parameter from 1 second to 300 seconds. On a > test Tor Hidden Service we managed to upload more than 1.5GB without > any problem while with the default setting we had trouble even > uploading 4-5MB. > > > Here's the patch for web2py that adds the parameter --socket-timeout > and lets the user tweak this setting: > https://github.com/globaleaks/web2py/commit/75f84697c3db70c1f4da4550f1518ced879208ce > > It would be great if this were merged to trunk so we don't have to > keep our own custom branch of web2py
The patch looks good to me. I'm curious: what was the threshold that made your case work? Did you need all of the 300 seconds?
