Re: Does Tomcat 5 users java.nio?

[Vy Ho]

Thank you both for the information.  I see it very clear now.  I would 
like to add my opinion on this though.  For the case of serving static 
content, if performance gain is significant, it would be the right way 
to move to new io (just for static content portion).  The reason is 
this: as Tomcat gets more complete and widespread, the missing part is 
ease of use.  Having to install Apache and Tomcat obviously is not a 
convienient thing to do for many people, especially new users.  Learning 
both obviously a steeper learning curve than one of them. Also, 
maintaining them both just for static content does sound good.  So, 
besides providing a good graphical tool for configuration of Tomcat, 
adding this seems to be the right thing to do.  However, this is based 
on the assumption that moving to new io is an easy thing to switch over 
in Tomcat, and no other better alternative to improve this performance 
(except the alternative and this method both improve the performance 
greatly, then why not do both).

Shapira, Yoav wrote:
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]
 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]