From modules-dev-return-4436-apmail-httpd-modules-dev-archive=httpd.apache.org@httpd.apache.org Fri Sep 27 09:43:00 2013 Return-Path: X-Original-To: apmail-httpd-modules-dev-archive@minotaur.apache.org Delivered-To: apmail-httpd-modules-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6E78310693 for ; Fri, 27 Sep 2013 09:43:00 +0000 (UTC) Received: (qmail 21661 invoked by uid 500); 27 Sep 2013 09:42:42 -0000 Delivered-To: apmail-httpd-modules-dev-archive@httpd.apache.org Received: (qmail 21604 invoked by uid 500); 27 Sep 2013 09:42:33 -0000 Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: modules-dev@httpd.apache.org Delivered-To: mailing list modules-dev@httpd.apache.org Received: (qmail 21578 invoked by uid 99); 27 Sep 2013 09:42:25 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Sep 2013 09:42:25 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of sorinm@gmail.com designates 209.85.212.175 as permitted sender) Received: from [209.85.212.175] (HELO mail-wi0-f175.google.com) (209.85.212.175) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Sep 2013 09:42:18 +0000 Received: by mail-wi0-f175.google.com with SMTP id ez12so533540wid.8 for ; Fri, 27 Sep 2013 02:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=7sfyvvq9w8I4S7ciosoTRK1RsnHSohiLbvCmsJ/19Ig=; b=XNqtOx2SWRPeIci05D/bZNq2COLzFIfwZZ2xyGZA751o/nQyw/o+QRddjq5JjlSoJJ QGuOVGPtUDpFY46O2tkY88DTFZ3OLrQ8fV4eVVStH7Gui7eFo8IrLtidFn7km5uyL65i bWNg3cVDbMf+r+KpAYhvicWcTeQ2L9WCSvSYrvyKp5ZWOJB5W7XmbvWDrx38qGQSkq+C Hj0K0EUKP1T0yNjht5v9RUtUYBadvpSQ58TBbxAkocGG5ZMnaaC5BxHgtbZUH17SEyRc cNF/vsy2RJzTHYt/Dp9hZq9pqute21rLbhLch2ZWfAv/u21mvxkdZNQNDePGWwNmWlx/ 4ahQ== X-Received: by 10.180.39.134 with SMTP id p6mr1825728wik.9.1380274918072; Fri, 27 Sep 2013 02:41:58 -0700 (PDT) Received: from ?IPv6:2a01:c9c0:a1:15:213:72ff:fe38:2e23? ([2a01:c9c0:a1:15:213:72ff:fe38:2e23]) by mx.google.com with ESMTPSA id ey4sm12196965wic.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 02:41:57 -0700 (PDT) Message-ID: <5245529D.9020000@gmail.com> Date: Fri, 27 Sep 2013 11:40:45 +0200 From: Sorin Manolache User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: modules-dev@httpd.apache.org Subject: Re: response handling inside ap_hook_create_request cb function References: <52452CDF.3090906@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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 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 >>> >>