tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filip Hanik" <>
Subject RE: + 4.1.x future
Date Sat, 13 Dec 2003 06:37:01 GMT
The tomcat clustering uses NIO for the session replication,
here is another fact, NIO sucks pretty bad in almost all the VMs.
In some of them, it just doesn't work as advertised at all.

I agree with Remy, it will not change the scalability that tomcat currently
because of the nature of the HTTP protocol. What you should be doing for a
heavy load
is to turn off keep alive for one thing, so that you don't have threads
waiting for nothing.


-----Original Message-----
From: Remy Maucherat []
Sent: Friday, December 12, 2003 1:38 PM
To: Tomcat Developers List
Subject: Re: + 4.1.x future

Jan-Henrik Haukeland wrote:
> Remy Maucherat <> writes:
>>My opinion is that NIO is going to be really useless.
> Eh, hello!? Oh, okay if it's not important that Tomcat scale and
> perform well it may be useless. But, really, before NIO it was
> hopeless to try and write a scalable and fast tcp server application
> in Java. Tomcat's current connection handling with blocing all over
> the place and "thundering herd" problem doesn't scale or work very
> well under heavy load.

You apparently have a very strong opinion on this, and that's fine. You
also obviously don't know what you are talking about. The purpose of
Tomcat is to make the web tier of an application server (Tomcat is
actually a mini application server), not some kind of non blocking I/O
toolkit to be used to build fixed function servers. Non blocking I/O has
great applications, and is a very useful technology, but it does not
apply to the application server world.

I think you should find a servlet container which has NIO, compare with
Tomcat 5.0.16, and come back to report your findings about how much
scalability or speed NIO brings (note: doing the non blocking socket
handling in a native layer doesn't really count, since it's not a fair
comparison with Java's NIO; you might as well use Apache).

Bring facts, not useless rants.


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message