Thanks Sorin. I'll check this up as well.
On Fri, Sep 27, 2013 at 3:10 PM, Sorin Manolache <sor...@gmail.com> wrote:
> 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
>>>>
>>>
>
