Hey, Last night I just after I sent this e-mail I possible found a way to do connection management in NIO. It will be a lot of work, but the benefits out weight this.
I figured I will extend DefaultConnectingIOReactor, and override: processSessionRequests(). In the custom version I'll just manage a list of SocketChannel's. But on closer inspection I noticed it's a private method. No overriding. So I'd have to copy it. I was thinking, maybe implementing it by fetching the connection with a getConnection() method, which returns a wrapper for a SocketChannel. This connection object would also implement the prepareSocket() method, so it can regulate only "preparing" it once. It could also perhaps have a set of attributes, so you can ship meta information with your connection (like some object you wish to be passed along with events). Maybe also an extension on org.apache.http.HttpConnection. Something like NHttpConnection. Just a suggestion. Q On 6/22/08, Quintin Beukes <[EMAIL PROTECTED]> wrote: > Hey, > > I was busy stepping the NIO code, and noticed the following: > this.dispatchers[this.currentWorker++ % this.workerCount].addChannel(entry); > > Is this safe? Since currentWorker will eventually wrap around to a > negative number. It will take a while, a long long while, but I don't > notice any resets anywhere, so I assume after running for a few > months, or under extremely high volume it will eventually fail. > > PS: Of all the open source projects' source code I've worked with, > HttpComponents have been the biggest pleasure of all. The code is > very... "intelligable". Sometimes code is over "complexified", or made > so abstract that one cannot see how things link up with each other, or > just badly written. Thanks for it all! > > Busy downloading the latest beta, then going to bed. > > Good night... > Q > > > On 6/22/08, Quintin Beukes <[EMAIL PROTECTED]> wrote: > > > (2) Be careful with blocking behaviors. If your code gets blocked while > > > executing on the I/O dispatch thread, this will effectively block _all_ > > > connections. No I/O events could be dispatched anymore. > > > > > > I figured this, and made sure that the IO dispatch thread does nothing > > more than set a variable and release a latch. > > > > > > > > > > (3) HttpCore does not provide a sophisticated connection management > > > mechanism similar to that in the HttpClient package. This is something > > > that we still plan to build at some point. Currently one need to write > a > > > lot of management code to control the behavior of the connecting I/O > > > reactor. > > > > > > This I also know, but with NIO, is there even a way to do connection > management? > > > > I figure I'd take your advice and get this thing running for > > Wednesday. I don't know how HttpClient does this, but I figure I'd > > just force make a new connection on the second try :/ > > > > But Wednesday is just 3 days away. Are there any examples that does > > persistent NIO connections? > > > > > > Q > > > > > > -- > > Quintin Beukes > -- Quintin Beukes --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
