httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saju Pillai <>
Subject Re: Asynchronous request processing
Date Mon, 09 Mar 2009 09:47:20 GMT
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.


View raw message