Dan,
You general purpose server sounds interesting - as there does appear to be more cases of multiple protocols being sent to the same port for some reason. However I think it would be a little too complex and perhaps slow for a general Jetty listener. My intentions for a NioListener for Jetty is to follow the model I used for the NBIO listener. That is a select set is only used for accepts and "idle" connections. An connection is idled after a response has been sent if it is persitent and no bytes are available to be read. Once idle, the connection is put into the select set waiting for read or close events. Once a connection has been selected as readable, it will be taken out of the select set, switched to blocking mode, the socket extracted, a thread allocated and the standard jetty handling called for a request/response cycle. The advantage of this approach is that it does not break any of the existing connection handling, but does not tie up a thread per idle connection. Typically 90% of connections are idle at any given time, so this is a big saving for scaling up. Apparently the 2.4 servlet spec is going to have some more support for nio built in - but they have not said what that will be (and will probably only tell the "community" after it is all too late to change). cheers Dan Christopherson wrote: > This is maybe a bit offtopic, and a bit long, but this is one of those > serindipitous occasions where a conversation strikes on something > somebody else is already working on... > > Greg Wilkins wrote: > > > >+ Use java.nio as: > > * if you care about performance you should be using jdk1.4 anyway > > * if you want one machine to handle more connections than the sum of > > all your servers, then java.net.ServerSocket aint going to do the job! > > * I want to play with nio before I write the NioListener for Jetty! > > Hmm. I've been writing a sort of general purpose TCP server using the > NIO stuff that I'd actually rather like to try grafting onto the front > end of Jetty, if you don't mind. Bear in mind that this is fairly early > work yet, and there are probably lots of holes. > > Basically, the way it's structure is there is a Server (MBean) which > contains listeners (one for each declared hostname:port). The Server has > a single thread that uses an NIO selector to find out when it needs to > accept on any of them. The resulting SocketChannels are handed off to a > ReaderManager, which chooses a ReaderThread to handle that channel. Each > reader thread selects on all of its channels, reads data and delegates > to a Protocol implementation to build a Request and put appropriate data > into it. Once the request gets to the state HEADERS_READ (the headers > have all been read and there is enough there to be dispatched) the > Reader thread hands gets a worker thread from a pool and hands the > Request off to a ContextManager which uses information from the request > to dispatch to the appropriate RequestHandler stack (which is where I > _think_ Jetty would come in). When the request needs to be written to > its output (because it's buffer is full, or the request has been > completely handled) it (carrying its SocketChannel) gets handed > off/hands itself to a WriterManager, which chooses a WriteThread to > handle it in a similiar non-blocking fashion as the ReaderThread. > > Note that a POST request (or an SMTP command, or a JBossMQ message on a > new protocol, or anything that can distinguish header/envelope from > body/payload) can be dispatched and processing can begin while the > request body is still being read. Likewise on the output: if the buffer > is full, it will start to be written while processing continues. > > ReaderThreads hold onto SocketChannels until they're closed (to enable > keep alive), WriterThreads do not. > > Direct Byte Buffers are used and pooled wherever possible, allowing > the underlying implementation to optimize transfers. > > I think the biggest advantage here is the level of control it gives > administrators over thread usage: you can configure read, write, and > work pools separately. One of the things people notice in JBoss under > linux is the number of threads used - they'd notice it under Windows or > any commercial Unix as well if they looked, it's just that Linux puts > its threads right out there for you to see and freak out on in ps and > top et. al. > > Another thought I've had is to use this same framework as the basis for > a new invoker for JBoss, so that remote client invocations don't put the > server at the mercy of the whims of RMI's thread usage. > > thoughts, chortels, flames? > > thanks for your time, > danch > -- Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK. Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
