On Mon, 2008-06-23 at 14:07 +0200, Quintin Beukes wrote: > 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. >
It can be easily made protected. > 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. > The way I see it, NIO connection management can be implemented by providing a more sophisticated implementation of IOEvenDispatch. One can use #connected and #disconnected methods to maintain a set of open sessions. That would be a reasonable starting point. Oleg > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
