On Sat, 2008-06-21 at 18:17 +0200, Quintin Beukes wrote: > 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. >
>From my personal experience classic I/O and NIO models are completely different and both serve to solve different kind of problems. They do not quite mix. Stick to the classic I/O because it is simpler unless you are absolutely sure your application needs ability to handle HTTP requests / responses asynchronously. > 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? > What are the functional requirements you are trying to fulfill? What is it exactly you are trying to achieve? > 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. > Why would you need anything else? A connection is either re-usable or not? Oleg > 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] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
