hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Quintin Beukes" <quin...@last.za.net>
Subject Re: NIO Connection Management
Date Tue, 24 Jun 2008 06:15:17 GMT
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.


On 6/23/08, Oleg Kalnichevski <olegk@apache.org> 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@hc.apache.org
>  For additional commands, e-mail: dev-help@hc.apache.org

Quintin Beukes
View raw message