NIO Connection Management

[Q Beukes]

Hey,

I checked out the EventDispatch thread the other day.. the
createConnection() inside the connected() method is what drew my
attention to it.

Problem is that I put a breakpoint there, and the connection is
already made to the target host (according to netstat), by the time
that break point is reached. It seems to me that the connected()
method is more what wraps IOSession (thus the Channel) inside a
DefaultNHttpClientConnection object.

So you can't really manage the connections, as a new physical
connection is already made at this point.
--
Quintin Beukes

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[olegk]

On Mon, 2008-06-23 at 21:01 +0200, Quintin Beukes wrote:

> Hey,
>
> I checked out the EventDispatch thread the other day.. the
> createConnection() inside the connected() method is what drew my
> attention to it.
>
> Problem is that I put a breakpoint there, and the connection is
> already made to the target host (according to netstat), by the time
> that break point is reached. It seems to me that the connected()
> method is more what wraps IOSession (thus the Channel) inside a
> DefaultNHttpClientConnection object.
>
> So you can't really manage the connections, as a new physical
> connection is already made at this point.

It is true, but this helps you keep track of open connections, right?
You can easily add more control logic around ConnectingIOReactor in
addition to that.

So, i think a viable approach could be to build the connection
management code as an extra control layer on top of both IOEventDispatch
and ConnectingIOReactor interfaces. A connection manager would act as a
facade for the connecting I/O reactor. It could keep track of open
connections and delegate the process of establishing new connections to
the I/O reactor if needed. The user would interact with the connection
manager and not directly with the I/O reactor.

Does this make any sense?

Oleg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Sam Berlin]

> It is true, but this helps you keep track of open connections, right?
> You can easily add more control logic around ConnectingIOReactor in
> addition to that.
>
> So, i think a viable approach could be to build the connection
> management code as an extra control layer on top of both IOEventDispatch
> and ConnectingIOReactor interfaces. A connection manager would act as a
> facade for the connecting I/O reactor. It could keep track of open
> connections and delegate the process of establishing new connections to
> the I/O reactor if needed. The user would interact with the connection
> manager and not directly with the I/O reactor.
>
> Does this make any sense?

Yes, this makes very much sense.  We swap in our NIO layer (which
essentially is our own version of an IOReactor, used across the entire
program for many other things) by having a ConnectingIOReactor
implementation that delegates to our stuff.  If the connection manager
layer delegates to the ConnectiongIOReactor & IOEventDispatch, it will
continue to easily work with other NIO layers.

I do think that any nio-based connection manager will need to have
much finer-grained control than the blocking variant.  That is, some
additional ability to say, "Do I have a latent connection to host X?
If so, give it to me.  Otherwise, don't even bother connecting because
I want to do something else."  This is strictly from our use-case
though of wanting to optimize what sources are used.

Sam

[Q Beukes]

Yes, it does.

Makes sense to track the connection on the connected event. Where can
I get the latest CSV sources? Or didn't much change from the beta2?

I will have a look around, see how I can fit it in, and then give a
detailed explanation of this. When it's accepted I'll again take the
latest source, and implement it. Unless it's very complex I'll
probably have it done/tested it 2/3 days.

Q

On 6/23/08, Oleg Kalnichevski <olegk@...> wrote:

> On Mon, 2008-06-23 at 21:01 +0200, Quintin Beukes wrote:
>  > Hey,
>  >
>  > I checked out the EventDispatch thread the other day.. the
>  > createConnection() inside the connected() method is what drew my
>  > attention to it.
>  >
>  > Problem is that I put a breakpoint there, and the connection is
>  > already made to the target host (according to netstat), by the time
>  > that break point is reached. It seems to me that the connected()
>  > method is more what wraps IOSession (thus the Channel) inside a
>  > DefaultNHttpClientConnection object.
>  >
>  > So you can't really manage the connections, as a new physical
>  > connection is already made at this point.
>
>
> It is true, but this helps you keep track of open connections, right?
>  You can easily add more control logic around ConnectingIOReactor in
>  addition to that.
>
>  So, i think a viable approach could be to build the connection
>  management code as an extra control layer on top of both IOEventDispatch
>  and ConnectingIOReactor interfaces. A connection manager would act as a
>  facade for the connecting I/O reactor. It could keep track of open
>  connections and delegate the process of establishing new connections to
>  the I/O reactor if needed. The user would interact with the connection
>  manager and not directly with the I/O reactor.
>
>  Does this make any sense?
>
>  Oleg
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@...
>  For additional commands, e-mail: dev-help@...
>
>

--
Quintin Beukes

[olegk]

Quintin Beukes wrote:
> Yes, it does.
>
> Makes sense to track the connection on the connected event. Where can
> I get the latest CSV sources? Or didn't much change from the beta2?
>

The latest SVN snapshot can be found here. You should always develop new
code off the trunk

http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/
http://www.apache.org/dev/version-control.html

Oleg

> I will have a look around, see how I can fit it in, and then give a
> detailed explanation of this. When it's accepted I'll again take the
> latest source, and implement it. Unless it's very complex I'll
> probably have it done/tested it 2/3 days.
>
> Q
>
> On 6/23/08, Oleg Kalnichevski <olegk@...> wrote:
>> On Mon, 2008-06-23 at 21:01 +0200, Quintin Beukes wrote:
>>  > Hey,
>>  >
>>  > I checked out the EventDispatch thread the other day.. the
>>  > createConnection() inside the connected() method is what drew my
>>  > attention to it.
>>  >
>>  > Problem is that I put a breakpoint there, and the connection is
>>  > already made to the target host (according to netstat), by the time
>>  > that break point is reached. It seems to me that the connected()
>>  > method is more what wraps IOSession (thus the Channel) inside a
>>  > DefaultNHttpClientConnection object.
>>  >
>>  > So you can't really manage the connections, as a new physical
>>  > connection is already made at this point.
>>
>>
>> It is true, but this helps you keep track of open connections, right?
>>  You can easily add more control logic around ConnectingIOReactor in
>>  addition to that.
>>
>>  So, i think a viable approach could be to build the connection
>>  management code as an extra control layer on top of both IOEventDispatch
>>  and ConnectingIOReactor interfaces. A connection manager would act as a
>>  facade for the connecting I/O reactor. It could keep track of open
>>  connections and delegate the process of establishing new connections to
>>  the I/O reactor if needed. The user would interact with the connection
>>  manager and not directly with the I/O reactor.
>>
>>  Does this make any sense?
>>
>>  Oleg
>>
>>
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: dev-unsubscribe@...
>>  For additional commands, e-mail: dev-help@...
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...