The Tomcat 5.5 release sports increased performance and an improved internal structure. Although not a stable release, it sets the tone right for a solid 5.5 release, replete with significant additions, a possible change in packaging, dependencies, and Tomcat internal APIs. Out of the box, Tomcat 5.5 requires the Java 2 Standard Edition Runtime Environment (JRE) version 5.0 or later. However, you can also run Tomcat 5.5 on earlier versions of the JRE.

Tomcat 5.5 uses the Eclipse JDT Java compiler for compiling JSP pages.

Some of the changes in Tomcat version 5.5.0 include:

• The usage of usage of commons-logging has been extensively used with the org.apache.catalina.Logger now removed
• With a view to better handle JAR and general resource locking, the classloader code has been refactored
• To leverage J2SE 5.0s built-in JMX abilities JMX-related code has been added
• The server startup performance as well as the request mapping and processing pipeline has been extensively profiled and optimized

Are the changes to Tomcat 5.5 reason enough to justify a significant jump from version 5.0 to 5.5? What would be the features that you'd love to see in a solid Tomcat 5.5 stable release?

For more information, go here:
Apache Jakarta Tomcat 5.5.0 Released

Tomcat 5.5 Change Log

It would be cool to have an optional integration path for Asynchronous IO for Java

It would be cool to have an optional integration path for Asynchronous IO for Java

Is there any benchmarks on it. Not only C10K, but C1000 or lower?

The IBM chaps were supposed to have posted a benchmark but I haven't seen it yet. But I guess on Windows , it can do C10K or better.

Can Tomcat precompile JSPs on startup yet? That's something I really like in Websphere. Yes, I know you can hack this together with an Ant task, but I'd prefer that it be an integrated setting.

It would be cool to have an optional integration path for Asynchronous IO for Java

It's not so simple. J have been working on it. I have a prototype (very, very alpha version) which uses SEDA, original Tomcat 5.25 request pipeline and
aio or netty-2 for io (it's distributed as a connector). And gues what - i'ts about 20% slower than original (aio is significantly faster than netty). The problem lies in the need of buffering data and there's no simple solution. You have to keep data in the buffer untill it's actually sent (in aio) or till it gets to the writting worker thread (netty).
.What's more, it uses much more memory because you have to keep a huge pool of direct buffers. The funny thing is that on windows nio allocates a direct buffer even when you use the byte[] methods. So you end up with out of memory very quickly, because java deallocates direct buffers very, very slowly.

You are right about NIO. Even Jetty seems to have backed away from NIO . It strange to hear so muchh about NIO and AIO only to have them proven as a wash.

PS : also is your AIO and NIO (netty) enabled Tomcat code avialable somewhere so maybe we can play with you code.

You are right about NIO. Even Jetty seems to have backed away from NIO . It strange to hear so muchh about NIO and AIO only to have them proven as a wash.

NIO is not a magical technology from Sirius. To be able to be more efficient in server software, Java should provide a better implementation of concurrency and parallelism at the core level. Take a look at Erlang for example (a functional, concurrency oriented language):

http://www.erlang.org/

Also, take a look at Yaws web server (written in Erlang):

http://yaws.hyber.org/

I think tomcat enhance the cluster function, it will very usefull.

If you could be more specific about enhancements you'd like to see in Tomcat's clustering, and if you could post your suggestions to the tomcat-user mailing list, we'd be glad to comment/evaluate/discuss/implement them. Just saying that the clustering features should be enhanced without giving specifics is not likely to result in any action ;)

How about,
- sticky session support.
- Better diagnostics/logging for session replication.
- Unified, cluster-wide JMX monitoring (eg. number of active session across the cluster).
- Cluster management from the admin console. Visually view the cluster nodes, which are active/inactive, ability to drain nodes to a stop.
- Better doc for all the clustering features, like cluster-wide deployment, session replication logging/debugging, etc.

How about, - sticky session support.- Better diagnostics/logging for session replication.- Unified, cluster-wide JMX monitoring (eg. number of active session across the cluster).- Cluster management from the admin console. Visually view the cluster nodes, which are active/inactive, ability to drain nodes to a stop.- Better doc for all the clustering features, like cluster-wide deployment, session replication logging/debugging, etc.

Tomcat 5.0.19 and newer have the ability to output the Status servlet data in XML format, which JMeter 2.0 can monitor. Jmeter 2.0 will show a status of each server you want to monitor and it can show a graph of the last 1000 samples. So some of the functionality is provided by other Jakarta projects like jmeter. I'm bias, since I'm a jmeter committer and I wrote the monitor for tomcat 5.x. http://jakarta.apache.org/jmeter

We're getting more specific, that's good.

- Sticky sessions have been supported for a long while now.
- The cluster code has what appears to me a reasonable number of logging statemets. They're now all commons-logging so you can control the verbosity by configuring commons-logging. If you'd like specific logging statements added, we'll be glad to do so, send .diffs to the mailing list.
- The admin console is designed to be confined to one server. While it might be interesting to enhance it to monitor a whole cluster, that job right now is left to console like MC4J [which support Tomcat out of the box]. Tomcat 5.5 uses JDK 5.0's built-in JMX support to make JMX intergration and monitoring even easier.
- The Doc is at http://jakarta.apache.org/tomcat/tomcat-5.0-doc/cluster-howto.html (plus the JavaDoc is available of course). Any additions you want, feel free to suggest, but just saying "better doc for all the clustering features" is almost as useless as saying "better clustering functionality" ;)

And again, the best place to discuss these is the tomcat-user list (tomcat-user at jakarta dot apache dot org), whose discussions are archived so we can take a look at them whenever we're bored and have nothing to do but work on your vague suggestions ;) [Your meaning not you specifically, but everyone]

- Could you please point to the doc for sticky session support?

- Could you please point to the doc for enabling debug logging of the container, particularly through commons-logging? I only see references to adding "debug" attributes to the server.xml config? Btw, i did enabling logging using commons/log4j, and I'm getting partial success, but I'm still not getting meaningful session replication messages?
I posted this particular problem to the tomcat-user list yesterday,
(http://www.mail-archive.com/tomcat-user at jakarta dot apache dot org/msg135052.html).

- MC4J is nice, but i don't believe it provides a unified cluster console. Rather is lets you manage each node as individual end-points (please correct me if i'm mistaken). Btw, another nice feature of a cluster console would be cluster-wide log viewing.

- Regarding doc, assuming it does not already exist, i would like to see mention of sticky sessions support/config, debug logging support/config (particularly in the context of session replication), cluster-wide (farm) deployment support/process, discussion of cluster management considerations (including the use of MC4J if applicable), discussion of real-world (no single point of failure) load-balancing options (eg. Windows NLB), ...

Thanks Yoav.

I'd love to see a solution that gets around the problem of a Single Point of Failure when clustering.

Thanks,

David

Maybe I'm spoiled by commercial software but there is no real good "single" source of documentation on clustering implementation and configuration. Yeah there is a overview doc called "how to". After hours of searching and reading between the lines and finding confusing and nonsensical documents on various sites I was able to figure it out or at least I think it is working. I think part of the problem is what I wanted to implement and how Tomcat implements it, lack of real how to (step by step) documentation which details out specific configuration steps, and differences between clustering in Tomcat versions which people carry over configs and are listed as how to but don't work between versions for example "sticky_Sessions=1" versus "stickySessions=1". I want multiple JVM's on each server. With multiple servers in a cluster that has sticky sessions but will also be load balanced on each server but not between servers since I have a hardware load balancer and to make it worse, stuck with IIS as a requirement and no development support to make sessions persist(serialized). I was perplexed as to what was the switch that turns clustering on? is it "<distributeable/>" in the web.xml?, do you have to have multicasting on to cluster? but I'm not doing session replication... Do you have to have session replication if you have multiple JVM's? are there difference with just multiple listeners versus multiple JVM's in a cluster? Any one of these things aren't well explained on how to specifically implement its configuration or alternate configs let alone all together and through my internet search agnst found alot of people in the same boat except for developers who write code or utilities for Apache or Tomcat and know the code/functionality and say "what's your problem, there's a how to that says nothing about physical implementation that tells you everything!". Yet alot of people who manage and operate Apache and Tomcat are not developers but System Administrators and the like. I think some are just asking for help to implement what great work developers have created.

What I've been sorely missing is an API to do programmatic login. Access to Tomcat's authentication and authorization mechanisms would be greatly appreciated.

I would like a way to read a request body from an Authenticator and still pass that request along to be re-read by the eventual servlet. I think there was a wrapper for Valves at one point, but there was no way to make it work with the Authenticator interface.

This came up when I tried to implement a custom authenticator for a binary protocol that ran over http. It stored the credentials along with the rest of the message in the body, and I couldn't find a way to read the body twice.

-Ryan Rhodes