Hey, Basically my program works like this:
I have incoming connections. NIO or Blocking IO can be used by configuration. Which doesn't really matter, as thread pools handle the connections anyway, exposing the connecting client's IO as streams. Then, inside these threads I will be doing connections out to the server. It's basically a custom load balancer. So, on top of all this, I have to create 2 new threads like mentioned above, and then my existing threads will send the request to the IO reactor, and go into pause. With this, my event handlers will be basically set an InputStream in a separate thread and "notify" it to continue, which makes the event handler basically forget about it, and my threads try and consume all content + return. Would this design work? Regarding, connection management ? Would I still be able to implement all my connection re-use logic? I noticed a ConnectionReuseStrategy, but that won't work, because it simply returns true whether or not the connection should be reused. thanks, Q On 6/21/08, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > On Sat, 2008-06-21 at 02:40 +0200, Quintin Beukes wrote: > > Hey, > > > > Hopefully someone is still around to answer this question. > > > > I had a look at the NIO of HttpCore (module-nio). Specifically the > examples. > > > > I noticed the client connections are done in a separate thread. Does it > have > > to happen in a separate thread? Do I need a thread for every "persistent" > > connection? > > > Quintin, > > You only need 2 threads: one for the I/O reactor and a controller thread > to control the I/O reactor. All new connections are established on the > I/O reactor thread. > > > > > > I assume not. I haven't had a proper look, as I'm going to bed myself > now. I > > just want to confirm something. > > > > I create the new connection by adding an object of my choice to the > context > > and then connecting it to an IO reactor. Here can be any number of > > connections to any number of different hosts, and I just handle each one > by > > using it's attachment in the event handlers? > > > > > Yes. > > > > So it's basically just set up, and everything then happens via events > which > > is executed in a single dedicated thread for ALL connections to ALL > hosts? > > > > > Yes. > > > Oleg > > > > Q > > > > On 6/21/08, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > > > > > Quintin Beukes wrote: > > > > > >> Will NIO connections work? > > >> > > >> > > > Yep. NIO is event driven, so the I/O selector will trigger an event if > a > > > channel gets closed by the other side > > > > > > Oleg > > > > > > PS: I'm off to bed. Wife is angry. > > > > > > On 6/21/08, Quintin Beukes <[EMAIL PROTECTED]> wrote: > > >> > > >>> Hey, > > >>> > > >>> So.. keepalive is sort of useless then? Because I realised what my > > >>> problem > > >>> is. It wasn't synchronization. It was because connections closed by > the > > >>> server, and then it fails when I try to re-use the connection. > > >>> > > >>> Basically what I have is this: > > >>> I try once, if receiving a NoResponse exception, I remove it from the > > >>> pool > > >>> and try again > > >>> If second try fails as well, it gets removed and I try again but with > an > > >>> isStale() check first. > > >>> > > >>> My problem is that these keep failing until I filtered through all > > >>> connections in the pool. In which case I start making new ones. > > >>> > > >>> How does HttpClient handle this? Or what can I do to improve this > into > > >>> being more reliable (in the sense of reducing failures to a minimum). > > >>> > > >>> Q > > >>> > > >>> On 6/21/08, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > >>> > > >>>> Quintin Beukes wrote: > > >>>> > > >>>> Hey, > > >>>>> > > >>>>> Isn't isStale() supposed to be able to tell me whether the server > is > > >>>>> accepting responses? > > >>>>> > > >>>>> > > >>>>> No, it is intended to test if the connection is still valid on the > > >>>> client > > >>>> side. Blocking I/O provides no good means of telling if the socket > has > > >>>> been > > >>>> closed by the peer. #isStale is a work-around for the problem. > > >>>> > > >>>> Oleg > > >>>> > > >>>> > --------------------------------------------------------------------- > > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>>> For additional commands, e-mail: > [EMAIL PROTECTED] > > >>>> > > >>>> > > >>>> > > >>> -- > > >>> Quintin Beukes > > >>> > > >> > > >> > > >> > > >> > > >> > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Quintin Beukes
