httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Supun Kamburugamuva <>
Subject Re: Asynchronous request processing
Date Mon, 09 Mar 2009 10:17:26 GMT
Thanks for the quick reply. I have found this Event MPM for httpd. Is it
possible to use this for my scenario?


On Mon, Mar 9, 2009 at 2:47 PM, Saju Pillai <> wrote:

> Supun Kamburugamuva wrote:
>> Hi all,
>> I'm writing a httpd module. This module is a content generator.
>> When a request comes to this module it has to forward it to a remote
>> machine. In that sense this module makes httpd acts like a proxy server.
>> Talking to a remote machine can take some time and if I use the default
>> threading model, this app won't scale. When httpd delivers the request to
>> the module, I want to use my own thread pool and handle the request. After
>> handling the request I want to send the response to the actual client
>> through Apache server.
>> Is this model supported by httpd? If so, can you point me to some
>> documentation where I can learn more about it?
> My knowledge about this is almost 2 years old.
> At my earlier job, we faced an almost similar problem and the only good
> solution at that point was to extend the (then) experimental event mpm to
> suit our needs. This new mpm made httpd asynchronous on a module by module
> basis - this code is owned by a corporation and is proprietary.
> 1. The basic principle was to startup a "polling" thread in addition to the
> listeners and workers. The "polling" thread uses epoll() (or suitable
> variant) to monitor i/o on client,server socket pairs.
> 2. When a request comes that needs to be handled asynchronously, the module
> calls an api that pushes the "request object" + context data (the client
> socket and the socket connected to the remote machine) to the epoll set of
> the polling thread. The worker thread is now free to handle a new request.
> 3. The polling thread waits for i/o to occur on one of the epoll set.
> Depending on the i/o it updates some state info and pushes the socket back
> into the "worker queue". A free worker then picks up this connection and
> processes it as required - including running the protocol stack, which might
> end up running a module that could push the socket back to the polling
> thread.
> This implementation required changes to http protocol handling code, some
> apr_pool handling code and significant rehashing of the listener, worker
> code.
> The implementation scaled rather well, with just 5 worker threads handling
> 400 concurrent long running requests.
> srp
> --

Software Engineer, WSO2 Inc

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message