Hi, Will's response is great. I'll just add that the issue of using NIO in Tomcat has been discussed numerous times on the tomcat-dev list with quite a good amount of detail and debate. There was consensus not to do it every time. However, the issue is still open for future consideration, and may be done in the future. With Tomcat 5.5 now requiring JDK 1.4, it won't be a problem to rely on NIO in that and future branches.
Yoav Shapira http://www.yoavshapira.com >-----Original Message----- >From: Will Hartung [mailto:[EMAIL PROTECTED] >Sent: Tuesday, November 02, 2004 8:33 PM >To: Tomcat Users List >Subject: Re: Does Tomcat 5 users java.nio? > >> From: "Vy Ho" <[EMAIL PROTECTED]> >> Sent: Tuesday, November 02, 2004 3:03 PM > >> I checked this document: >> >> http://www-106.ibm.com/developerworks/library/j-nioserver/ >> >> and it talks about how wonderful new io could help server to serves >> higher number of connections and less error/drop connections. >> >> Is it true in practice? Does Tomcat 5 uses new io of just io? If not, >> do they plan to move to this? > >The dillema is that the Servlet Model as defined in the specification >doesn't work well in the kind of environment provided by NIO, so it's >difficult to say whether something that handled the semantics of a Servlet >written using NIO would actually be any faster at all. > >Now, technically, if one were so inclined, you could implement that bits >that handle static content with Tomcat to, perhaps, use the nio model and >maybe get a bonus for a pure Tomcat, yet static heavy, site. But since most >folks simply Don't Do That (i.e. if they're distinguishing static content >at >all, odds pretty good that they're fronting Tomcat with Apache anyway...), >there's little motivation to engineer Tomcat to support NIO for simply >static content. > >Servlets are pretty much thread based, being as they can perform arbitrary >calculations. Also, Servlets can, technically, access the input and output >streams of the request directly. Many servlets don't need that kind of >direct access. For example, most simply use the request headers and >parameters rather than the input stream itself. > >NIO based servers are essentially event driven, with the sockets and IO >channels being a dominant source of the events. The NIO server repeatedly >checks the two ends of a request (the source and the sink, for example, the >input stream and server logic). When the source has data ready to read and >the sink is ready to take data, the NIO server grabs a chunk from the >source >and feeds it to the sink, and then moves on to the other sources/sinks >within its queue. > >The main thread of an NIO server can NOT block waiting for something to >come >ready, as it will stall the entire server (because none of the other >requests will get serviced). If you're simply moving data from disk to a >socket, this works fine because OS's offer asynchronous IO calls and make >available routines which an NIO server can use to see "who's waiting" and >needs servicing. > >But exposing that "is it ready" interface to arbitrary logic like that >within a servlet is difficult. If the code is very short, it's no problem >at >all. The code is "always" ready and essentially returns immediately. But if >it's doing anything more than that (say, contacting a database), then >things >get more ugly very quickly. The IO drivers of the system are asynchronous >without directly using a user level mechanism like threads, so they're >asynchronous "for free". But if you want user written logic to have an >asynchronous behavior, we typically turn to threads to provide that for us. >But, the strength of the NIO model is that the requests it manages within >its internal queue have simple state than a thread, and therefore switch >from request to request is much cheaper (and therefor faster) than using >the >JVMs thread scheduler to switch between threads. > >But if the NIO server needs to spawn a thread to get asynchronous behaviour >from an arbitrary Servlet, then most of the benefit of the NIO architecture >is lost. > >Servers can certainly be written this way. Servers can perform all of the >things that a Servlet can provide. But the fine grained event model is much >different than what the Servlet specification provides, and it would also >require that all calls be basically event based, particularly calls to >things like DBs.\ > >Regards, > >Will Hartung >([EMAIL PROTECTED]) > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
