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
>