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

[Graham Leggett <mi...@sharp.fm>]

On 07 Feb 2014, at 3:54 PM, jim@apache.org wrote:

> Author: jim
> Date: Fri Feb  7 13:54:38 2014
> New Revision: 1565657
> 
> URL: http://svn.apache.org/r1565657
> Log:
> Add in the concept of "slave" connections...
> Allows for several "connections" all resulting in
> a single real connection that talks to the network.
> Right now, nothing uses this though.

Nice.

We also need the option to associate an arbitrary socket[1] to the slave connection, which could be created by mod_proxy, obtained from a connection pool, etc. I guess that is further down.

> +/** Create a slave connection
> + * @param c The connection to create the slave connection from/for
> + * @return The slave connection
> + */
> +AP_CORE_DECLARE(conn_rec *) ap_create_slave_connection(conn_rec *c);

How would we handle a connection pool scenario?

Here, we arrive, grab a connection from our pool, now we need to associate it with the frontend connection somehow. Ideally the pool cleanups should cover all the scenarios of tearing this down, returning to the connection pool, etc.

It depends on whether it is worth teaching the core how to be aware of connection pools, or if that is a step too far.

Regards,
Graham
--

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

[Jim Jagielski <ji...@jaguNET.com>]

On Feb 7, 2014, at 11:49 AM, Graham Leggett <mi...@sharp.fm> wrote:

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

True, and that's the relationship between the slaves
and the master... basically, the idea is that the slaves
will never interact w/ the network but only w/ the master.
Saying the a request's conn_rec will *always* be a slave
could provide some useful isolation. In a sense, it
moves the "master" connection more inner to core.

Of course, I have no idea how far this can go until
it takes too much effort and complexity to maintain
this master/slave concept. It did seem to help w/
mod_spdy and that's why I started in that direction...

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

[Graham Leggett <mi...@sharp.fm>]

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

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

[Jim Jagielski <ji...@jaguNET.com>]

On Feb 7, 2014, at 10:58 AM, Graham Leggett <mi...@sharp.fm> wrote:

> On 07 Feb 2014, at 5:34 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> 
>> These are all good questions, and I'm not sure what the
>> answer is right now... another one, maybe ap_run_create_connection
>> should return a *slave* connection (it creates both master
>> and its slave, but returns the slave). That would be much
>> more flexible for the MPM and the process_connection
>> phase, but would mean that core needs to Do The Right Thing.
>> 
>> But then again, why add that complexity if you don't need
>> it? That's what the hooks are for and if we need to create
>> slave connections, that's what pre_connection is for (and
>> how mod_spdy currently handles it).
> 
> True.
> 
> Thinking out loud I am wondering what the right layer is to do this at.
> 
> Ideally I would like to, at any time, for any reason, go "here is a conn_rec that already exists, add it to this group of conn_rec's in the event loop, treat this conn_rec like any other connection moving forward, go".
> 
> How that conn_rec leaps into existence should in theory not matter, maybe mod_spdy made some of them in one go, maybe mod_proxy grabbed one from a pool, shouldn't matter.
> 
> Ideally the "add this conn_rec to the event loop" should have appropriate pool cleanups such that it is automagically removed from the event loop if that conn_rec is destroyed.
> 
> There also needs to be a way to actively remove a conn_rec from the event loop, so that mod_proxy can return a connection to a pool when done.
> 

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.

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

[Graham Leggett <mi...@sharp.fm>]

On 07 Feb 2014, at 5:34 PM, Jim Jagielski <ji...@jaguNET.com> wrote:

> These are all good questions, and I'm not sure what the
> answer is right now... another one, maybe ap_run_create_connection
> should return a *slave* connection (it creates both master
> and its slave, but returns the slave). That would be much
> more flexible for the MPM and the process_connection
> phase, but would mean that core needs to Do The Right Thing.
> 
> But then again, why add that complexity if you don't need
> it? That's what the hooks are for and if we need to create
> slave connections, that's what pre_connection is for (and
> how mod_spdy currently handles it).

True.

Thinking out loud I am wondering what the right layer is to do this at.

Ideally I would like to, at any time, for any reason, go "here is a conn_rec that already exists, add it to this group of conn_rec's in the event loop, treat this conn_rec like any other connection moving forward, go".

How that conn_rec leaps into existence should in theory not matter, maybe mod_spdy made some of them in one go, maybe mod_proxy grabbed one from a pool, shouldn't matter.

Ideally the "add this conn_rec to the event loop" should have appropriate pool cleanups such that it is automagically removed from the event loop if that conn_rec is destroyed.

There also needs to be a way to actively remove a conn_rec from the event loop, so that mod_proxy can return a connection to a pool when done.

Regards,
Graham
--

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

[Jim Jagielski <ji...@jaguNET.com>]

These are all good questions, and I'm not sure what the
answer is right now... another one, maybe ap_run_create_connection
should return a *slave* connection (it creates both master
and its slave, but returns the slave). That would be much
more flexible for the MPM and the process_connection
phase, but would mean that core needs to Do The Right Thing.

But then again, why add that complexity if you don't need
it? That's what the hooks are for and if we need to create
slave connections, that's what pre_connection is for (and
how mod_spdy currently handles it).

On Feb 7, 2014, at 9:55 AM, Graham Leggett <mi...@sharp.fm> wrote:

> On 07 Feb 2014, at 3:54 PM, jim@apache.org wrote:
> 
>> Author: jim
>> Date: Fri Feb  7 13:54:38 2014
>> New Revision: 1565657
>> 
>> URL: http://svn.apache.org/r1565657
>> Log:
>> Add in the concept of "slave" connections...
>> Allows for several "connections" all resulting in
>> a single real connection that talks to the network.
>> Right now, nothing uses this though.
> 
> Nice.
> 
> We also need the option to associate an arbitrary socket[1] to the slave connection, which could be created by mod_proxy, obtained from a connection pool, etc. I guess that is further down.
> 
>> +/** Create a slave connection
>> + * @param c The connection to create the slave connection from/for
>> + * @return The slave connection
>> + */
>> +AP_CORE_DECLARE(conn_rec *) ap_create_slave_connection(conn_rec *c);
> 
> How would we handle a connection pool scenario?
> 
> Here, we arrive, grab a connection from our pool, now we need to associate it with the frontend connection somehow. Ideally the pool cleanups should cover all the scenarios of tearing this down, returning to the connection pool, etc.
> 
> It depends on whether it is worth teaching the core how to be aware of connection pools, or if that is a step too far.
> 
> Regards,
> Graham
> --
>