Re: AW: Module: Mod_Dialup (ap_mpm_register_timed_callback)

[Joe Lewis]

On 05/25/2012 02:58 AM, Pöchtrager, Bernhard wrote:
-----Ursprüngliche Nachricht-----
Von: Joe Lewis [mailto:jle...@silverhawk.net] Im Auftrag von Joe Lewis
Gesendet: Donnerstag, 24. Mai 2012 18:06
An: modules-dev@httpd.apache.org
Cc: Pöchtrager, Bernhard
Betreff: Re: Module: Mod_Dialup (ap_mpm_register_timed_callback)

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
The code of my Handler exits with SUSPENDED. If the Handler doesn't complete 
the Callback wouldn't get called.
Maybe I have to change the state of the handler, but how can I do this? Do you 
have any ideas to close the handler?

Here is my actual-Code of the Callback.
Static void callback(void* data) {
      request_rec* prr = (request_rec*) data;
      apr_thread_mutex_lock(prr->invoke_mtx);
      get_data(prr);            //here I get my data. It's like the handler I 
used for a synchronous connection
      apr_thread_mutex_unlock(prr->invoke_mtx);
      ap_finalize_request_protocol(prr);
      ap_process_request_after_handler(prr);
      prr->status=HTTP_OK;
      ap_die(DONE, prr);
}

The handler is:
static int async_handler(request_rec* prr)
{
     ap_mpm_register_timed_callback(apr_time_from_msec(1000),callback,prr);
     return SUSPENDED;
}

Question - the mod_dialup.c handler is generating content, but yours is 
not.  How are you generating a response?  Basically, the mod_dialup.c 
handler is sending the contents of a file (including the EOS bucket 
which is supposed to cause the connection to close), and returning 
SUSPENDED, which then triggers in the dialup_callback to either 
re-suspend, or process the request depending on the dialup_send_pulse 
result.

Curiosity - is the previous connection still open when you get to the 
second request that is failing?

Joe