You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modules-dev@httpd.apache.org by Ronald Park <ro...@cnet.com> on 2008/02/01 17:59:56 UTC

Behaviour for Connection: close

I'm writing a module which is intended to do it's work
'asynchronously'.  My module takes the body of a POST,
stores it into a note and immediately generates a response
code of 200.  Then, during the logging stage, it does
that actual work (in my case, writing stuff into a db).

I have 'KeepAlives off' and, as expected, Apache sends
back the 200 and 'Connection: close'... however, it does
not "immediately" close the socket.  It proceeds to do
logging and runs my code *then* closes the socket.

The behavior is fine for some clients, those that see the
'Connection: close' and close their connections themselves.
For them, my module is 'asynchronous'.  For others clients
though, ones which wait for the server to close, it's not;
their requests are practically synchronous (actually, a
little slower).

Is there a way to hook my module in absolutely after the
close is called?  Is there a way to get the socket close
to occur immediately after the response is sent?

Or, am I going to have to do something like spawning off
a thread, copying all the request data into that thread
(so it doesn't go poof when the request pool is destroyed)
and doing my work in that thread? :(

Thanks,
Ron


Re: Behaviour for Connection: close

Posted by Nick Kew <ni...@webthing.com>.
On Fri, 01 Feb 2008 11:59:56 -0500
Ronald Park <ro...@cnet.com> wrote:

> I'm writing a module which is intended to do it's work
> 'asynchronously'.  My module takes the body of a POST,
> stores it into a note and immediately generates a response
> code of 200.

Someone already mentioned 202:-)

> Is there a way to hook my module in absolutely after the
> close is called?  Is there a way to get the socket close
> to occur immediately after the response is sent?

No.  The Connection outlives the Request.

> Or, am I going to have to do something like spawning off
> a thread, copying all the request data into that thread
> (so it doesn't go poof when the request pool is destroyed)
> and doing my work in that thread? :(

Well, you could create a thread at child_init, and use
an apr_queue to pass data to it, preferably in fixed-size
chunks (else you're going to have fun managing memory).
Or if the requests are large, maybe spool them to disc
and you can process them entirely separately (c.f. mod_smtpd
or other mailserver).

-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

Re: Behaviour for Connection: close

Posted by John David Duncan <jd...@mysql.com>.
Hi Ronald,

I can't answer your question.  But I wanted to mention: as I  
understand the standard, you should be returning a "202 Accepted"  
rather than a 200 in this case.

JD



On Feb 1, 2008, at 8:59 AM, Ronald Park wrote:

> I'm writing a module which is intended to do it's work
> 'asynchronously'.  My module takes the body of a POST,
> stores it into a note and immediately generates a response
> code of 200.  Then, during the logging stage, it does
> that actual work (in my case, writing stuff into a db).
>
> I have 'KeepAlives off' and, as expected, Apache sends
> back the 200 and 'Connection: close'... however, it does
> not "immediately" close the socket.  It proceeds to do
> logging and runs my code *then* closes the socket.
>
> The behavior is fine for some clients, those that see the
> 'Connection: close' and close their connections themselves.
> For them, my module is 'asynchronous'.  For others clients
> though, ones which wait for the server to close, it's not;
> their requests are practically synchronous (actually, a
> little slower).
>
> Is there a way to hook my module in absolutely after the
> close is called?  Is there a way to get the socket close
> to occur immediately after the response is sent?
>
> Or, am I going to have to do something like spawning off
> a thread, copying all the request data into that thread
> (so it doesn't go poof when the request pool is destroyed)
> and doing my work in that thread? :(
>
> Thanks,
> Ron
>