On 6/1/12 2:36 AM, Pöchtrager, Bernhard wrote:
ap_die should, in theory.  Is your request handler adding in an EOS
bucket (end of socket) ?  Is anything calling the brigade functions in your
code?
No my request handler doesn't add an EOS bucket and I don't call the
brigade function.
Today I tried to take the mod_dialup without the file (I deleted every part
with the file). I mean I use all brigade functions, I append an EOS bucket and I
call the original dialup_send_pulse().
I modified the dialup_callback in this way:

apr_thread_mutex_lock(db->r->invoke_mtx);
get_data(db->r);     //I added this line of code to send the response. (This
is a stupid idea, but in my mind it should work) (Or should I send the
response as a bucket?)
status = dialup_send_pulse(db); //the status I get is done...

Even with this code I have the same problem...

I am working with keepalive requests. Is it possible that this isn't working
with keepalive requests?

It is definitely a possibility.  What happens if you replace the get_data
(probably the culprit to what you are doing) with the code from mod_dialup?
Does it work as expected?  If so, make the get_data() function behave a little
more like the mod_dialup code, doing what you want it to do.

Joe
My first problem with mod_dialup is that I can't read the file. Strangely enough 
the value of r->finfo.filetype is 0.
I changed the code and send only the EOS bucket. I receive a file (with 0 bytes 
and I can save it), but I have the same problem.
Every second request is loading the whole time.
I think I didn't make any mistake.
In my mind either keepalive isn't supported or mod_dialup doesn't work (it's 
experimental...).

Bernhard
Oh.. No.. The problem is definitly the keepalive. I turned keepalive off and 
everything works fine.
Thanks for your help


I'm responding with this to the list so that it can be recorded for future searches. Bernard, thank you for being willing to dig in and do some research, and I'm glad you have located a work around!

Joe

Reply via email to