On 2013-09-27 11:11, Pon Umapathy Kailash S wrote:
Thanks for your response, Sorin.
My concern in this approach is that - it would require one worker
thread to be held up for as long as this connection is open(and this
might be long + the number of clients can be higher than the worker
threads for my use-case/platform).
Given that the 1st handshake message is over http, i can setup the
connection in a handler hookup function and return a response, freeing
up the worker thread while keeping the connection persistent(plus save
the socket/ssl in a cache shared the worker threads).
Anyway in "normal" apache, i.e. over http, the worker threads are not
freed up after processing a request. An idle worker thread is assigned
to a connection when one is opened by a client for the whole duration of
the connection. You can check that in
modules/http/http_core.c:ap_process_http_sync_connection. You'll see
that ap_process_request is called in a loop. The loop is left when the
connection is closed. If the connection is idle, the worker thread is in
"KeepAlive" state. You can check this when looking at /server-status.
So it would not make any difference if you assigned a worker to the
connection in process_connection.
You'll have to take care though not to overuse the connection memory
pool because the pool is not destroyed while the connection is open, and
this could be a long time.
Now, when the next set of messages come in(which is not over http), I
would need to intercept these and add my handling(ideally write
something on the socket on which the message came and be done with the
request while keeping the connection persistent unless the message was
a control frame to close).
Regards,
Umapathy
On Fri, Sep 27, 2013 at 12:29 PM, Sorin Manolache <sor...@gmail.com> wrote:
On 2013-09-27 03:06, Pon Umapathy Kailash S wrote:
Hi,
Here is a quick background on what I am trying to do(basically adding
support for websockets - in a slightly customised manner as needed for
my app):
- Handle the initial handshake inside a cb function registered as a
handler hook(from here, I compute checksums required and return the
response headers as needed).
Also, the socket from which the request was read is stored in a cache.
- For subsequent message reception(on the same connection), i have a
function cb registered using ap_hook_create_request(since this is a
different protocol format message). Here, I read and parse the
messages/requests which are coming in from the cached list of
sockets(this is working).
However, once I return from this cb, the connection/socket seems to be
closed. I guess the request is further passed down to hooks down the
line and the connection is closed since the req format is not known.
What would be the best way to handle this scenario?
I have the following in mind:
- let the request not be processed any further(and keep the connection
on).
- create a req structure with dummy http headers that i can later
recognise and handle inside my handler hook to just ignore later on
are there any examples/notes on how these can be achieved?
In my opinion, it is too late to handle non-http in the create_request
callback.
The create_request callback is called from
ap_run_process_connection->ap_process_http_{sync|async}_connection->ap_read_request.
Your create_request callback returns to ap_read_request from where the
request is further processed as an http request.
In my opinion you should short-cut the http processing and hook
ap_hook_process_connection. However, there, in process_connection, you have
no request_rec, you have just a conn_rec. process_connection is called only
once per connection creation. So it should handle all the requests that
arrive while the connection is open.
Sorin
Regards,
Umapathy
