On 05/24/2012 03:26 AM, Pöchtrager, Bernhard wrote:
I created two files. One file with a strace of a successful request and one
with a strace of an unsuccessful request.
The first significant differences between these two requests are following
lines.
4171<... futex resumed> ) = -1 EAGAIN (Resource temporarily
unavailable)
4170<... futex resumed> ) = -1 EAGAIN (Resource temporarily
unavailable)
4169<... futex resumed> ) = -1 EAGAIN (Resource temporarily
unavailable)
4168<... futex resumed> ) = -1 EAGAIN (Resource temporarily
unavailable)
4167<... futex resumed> ) = -1 EAGAIN (Resource temporarily
unavailable)
4166<... futex resumed> ) = -1 EAGAIN (Resource temporarily
unavailable)
4164<... futex resumed> ) = -1 EAGAIN (Resource temporarily
unavailable)
4171 futex(0x1eda654, FUTEX_WAIT_PRIVATE, 42, NULL<unfinished ...>
4170 futex(0x1eda654, FUTEX_WAIT_PRIVATE, 42, NULL<unfinished ...>
4169 futex(0x1eda654, FUTEX_WAIT_PRIVATE, 42, NULL<unfinished ...>
4168 futex(0x1eda654, FUTEX_WAIT_PRIVATE, 42, NULL<unfinished ...>
4167 futex(0x1eda654, FUTEX_WAIT_PRIVATE, 42, NULL<unfinished ...>
4166 futex(0x1eda654, FUTEX_WAIT_PRIVATE, 42, NULL<unfinished ...>
4164 futex(0x1eda654, FUTEX_WAIT_PRIVATE, 42, NULL<unfinished ...>
Well I think that the first request didn't finish correctly. But what can I do?
Do you have any ideas?
Bernhard
"futex", based on "mutexes", are locking mechanisms and are used to
prevent work from being done while something else is working (e.g. on
data to prevent corruption). I am unfamiliar with
ap_mpm_register_timed_callback, so I pulled up the apache source to see
what it is doing. Apparently, the source has a comment in
include/httpd.h about it :
/** Mutex protect callbacks registered with ap_mpm_register_timed_callback
* from being run before the original handler finishes running
*/
Looking at the trace and seeing the comment indicates that the original
handler has not completed. In fact, if you look at the source file
modules/test/mod_dialup.c, it has an example but it uses the
apr_thread_mutex_lock and apr_thread_mutex_unlock functions in the call
back that is registered, and it re-registers the call back if it needs
to check again (e.g. if it still has data to send back to the client),
but it still unlocks the mutex.
Have you checked to ensure your handler has exited?
Joe
