Bug #1543
closedUpload stops with lighttpd 1.5 r1922.
Description
I use lighttpd 1.5 r1922, with mod_uploadprogress and mod_proxy_backend_fastcgi and randomly stops uploading and mod_uploadprogress debug says:
mod_uploadprogress.c.508: (trace) connection is known: b40ec1cbc4045b136bb8648be1358d52, sending: new Object({ 'state' : 'uploading', 'received' : 21590, 'size' : 78498729})
mod_uploadprogress.c.450: (trace) (uploadprogress) urls /progress /progress
mod_uploadprogress.c.508: (trace) connection is known: b40ec1cbc4045b136bb8648be1358d52, sending: new Object({ 'state' : 'uploading', 'received' : 190645, 'size' : 78498729})
mod_uploadprogress.c.450: (trace) (uploadprogress) urls /progress /progress
mod_uploadprogress.c.508: (trace) connection is known: b40ec1cbc4045b136bb8648be1358d52, sending: new Object({ 'state' : 'uploading', 'received' : 190645, 'size' : 78498729})
mod_uploadprogress.c.450: (trace) (uploadprogress) urls /progress /progress
mod_uploadprogress.c.508: (trace) connection is known: b40ec1cbc4045b136bb8648be1358d52, sending: new Object({ 'state' : 'uploading', 'received' : 190645, 'size' : 78498729})
mod_uploadprogress.c.450: (trace) (uploadprogress) urls /progress /progress
mod_uploadprogress.c.508: (trace) connection is known: b40ec1cbc4045b136bb8648be1358d52, sending: new Object({ 'state' : 'uploading', 'received' : 190645, 'size' : 78498729})
mod_uploadprogress.c.450: (trace) (uploadprogress) urls /progress /progress
mod_uploadprogress.c.508: (trace) connection is known: b40ec1cbc4045b136bb8648be1358d52, sending: new Object({ 'state' : 'uploading', 'received' : 190645, 'size' : 78498729})
mod_uploadprogress.c.450: (trace) (uploadprogress) urls /progress /progress
mod_uploadprogress.c.508: (trace) connection is known: b40ec1cbc4045b136bb8648be1358d52, sending: new Object({ 'state' : 'uploading', 'received' : 190645, 'size' : 78498729})
I`m attaching an strace output.
-- botond
Files
Updated by Anonymous almost 17 years ago
Recently we switched to 1.5. rev. 1992 on our production servers because we needed the new uploadprogress. This revealed a bug in the module.
If you leave server.max-worker at its default value all is fine, but on the production servers we had a larger value. This caused the uploadprogress module to randomly stop returning data with the following error:
mod_uploadprogress.c.450: (trace) (uploadprogress) urls /progress == /progress
mod_uploadprogress.c.485: (trace) connection unknown: 841ff6acdcd3b51d54361ea16a440cbc, sending: new Object({ 'state' : 'starting' })
It seemed that the processes did not share progress state between them. After we commented out the server.max-worker all is working perfectly. I did not dare to mess with the code :)
-- momchil
Updated by stbuehler over 16 years ago
- Status changed from New to Fixed
- Resolution set to invalid
Somehow the upload stream seems to have stopped - i think after 5 seconds a timeout kills the upload.
server.max-worker will of course not work together with uploadprogress, and that is a wontfix.
Also available in: Atom