On 07 Feb 2014, at 6:26 PM, Jim Jagielski <j...@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 --
