httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: svn commit: r1565657 - in /httpd/httpd/trunk: include/ap_mmn.h include/http_core.h include/httpd.h server/connection.c server/core.c
Date Fri, 07 Feb 2014 16:49:46 GMT
On 07 Feb 2014, at 6:26 PM, Jim Jagielski <jim@jaguNET.com> wrote:

> Some kind of callback for each conn_rec, such that when we are
> "done" with it, it knows what do to (rejoin mod_proxy's pool,
> pool cleanup, whatever).
> 
> In some ways, the "slave" connection actually behaves like
> a router, between the request and the "real" connection...
> it would also be nice to remove the thread-specific stuff
> to this slave connection.

Hmmm…

In theory all conn_recs should be treated equally, it would be up to each connection to know
and care about relationships each connection has with another connection, by adding appropriate
filters.

I think the key thing is not make any assumptions that close any doors for functionality.
For example, if there was an assumption that a slave connection existed as a child of a master
connection, we would have the unfortunate property that we could never put the slave connection
into a connection pool, or leave the slave going after the master had gone away for whatever
reason.

Imagine if mod_proxy set up a backend connection or nabbed one from a connection pool, then
added a set of filters to that backend connection and frontend connection that would glue
the two conn_rec's together for some sensible lifetime. It would be the job of those filters
to read from the one stack and then write to the other.

This enables some powerful event driven behaviour - mod_proxy can do all the potentially-blocking
stuff like DNS and establishing the connections, add the glue filters, then say "my work here
is done" and sit back and let the filter chains do their work asynchronously.

Regards,
Graham
--


Mime
View raw message