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 <sorinm@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
>>>
>>