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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Quintin Beukes
