Apache has announced that Tomcat 6.0.10 has been released and is considered stable. Tomcat 6 (download, documentation) implements the "Servlet 2.5 and JSP 2.1 specifications, a refactored clustering implementation, advanced IO features, and improvements in memory usage." The documentation for Tomcat 6 itself seems to be all right, but the web sites for Tomcat don't list many of the new features, mostly referring to Tomcat 5 as the latest stable release. Congratulations to the Apache Tomcat team!

Does anybody know whether tomcat 6 will be bundled with jboss 4 / jboss 5 ? I haven't found a clear answer on this on the net, but it looks like the jboss 5 beta is bundled with jboss' own servlet container (jbossws).

Does anybody know whether tomcat 6 will be bundled with jboss 4 / jboss 5 ? I haven't found a clear answer on this on the net, but it looks like the jboss 5 beta is bundled with jboss' own servlet container (jbossws).

Both JBoss 4.2 and JBoss 5 [will] include JBoss Web 2, which is almost identical to the Tomcat 6.0.10 source at the moment. It is kept as a separate source tree for maintenance reasons (for example, if there's a JBoss specific change which needs to go in, etc).

Does anyone have any insight into when JBoss 5 will be GA'd? I know it's currently in the beta phase, but I couldn't find any road map information on the JBoss site.

Maybe someone with views into the Tomcat development could tell me: Are there any plans to make Tomcat be able to use non-blocking IO (such as Java NIO), and be able to multiplex several client connection over a small number of worker threads? The current Apache and Tomcat model of 1 request - 1 thread is quite antiquated, and is really keeping potential maximum concurrency numbers down. A multiplexing NIO solution would be able to up the concurrency to potentially handle thousands of concurrent requests, as opposed to a few hundred (in fact we have been prototyping such an architecture on my current project). Furthermore, being able to allocate minimum number of thread resources to separate applications would also be highly useful, so as to not saturate a machine because one app or url-path is slow/failing. / Wille Blog: Buzzword Bingo

Maybe someone with views into the Tomcat development could tell me:
Are there any plans to make Tomcat be able to use non-blocking IO (such as Java NIO), and be able to multiplex several client connection over a small number of worker threads?

Go with Jetty 6 and never look back :-) S.

Unfortunately, Web application based on Servlet API is supposed to process request in a single thread. Some improvements may be done on the container part, but not in application code. If you need true asynchronous container forget standard Servlet API.

Unfortunately, Web application based on Servlet API is supposed to process request in a single thread. Some improvements may be done on the container part, but not in application code.

If you need true asynchronous container forget standard Servlet API.

Well, not necessarily.. You could actually have requests queueing up in in-memory queues BEFORE they get to the Servlet API, once they hit the Servlet API part, they would process in a traditional way - one request one thread, but you could use resources more efficiently before it hits a Servlet and thus increase concurrency and reliability.

Maybe someone with views into the Tomcat development could tell me:
Are there any plans to make Tomcat be able to use non-blocking IO (such as Java NIO), and be able to multiplex several client connection over a small number of worker threads?

The current Apache and Tomcat model of 1 request - 1 thread is quite antiquated, and is really keeping potential maximum concurrency numbers down.

I think that works great for serving files, but not necessarily for a servlet, because there is no way to suspend a servlet's execution when it's waiting on I/O - for example when it queries a database. In order to get better throughput in an average application you would have to have a programming model which uses cooperative multitasking - where each thread keeps running until it has to wait on I/O.

The current Apache and Tomcat model of 1 request - 1 thread is quite antiquated

Both Apache [HTTP Server] and [Apache] Tomcat allow using pollers / sendfile / and other techiniques which allow worker threads to focus on processing business logic rather than blocking on IO or serving static files. For Apache Tomcat, you should look at this documentation: http://tomcat.apache.org/tomcat-6.0-doc/aio.html

That's wondrful! I love how quickly Tomcat catches up on these things! Thanks again

The current Apache and Tomcat model of 1 request - 1 thread is quite antiquated

Both Apache [HTTP Server] and [Apache] Tomcat allow using pollers / sendfile / and other techiniques which allow worker threads to focus on processing business logic rather than blocking on IO or serving static files.

For Apache Tomcat, you should look at this documentation: http://tomcat.apache.org/tomcat-6.0-doc/aio.html

http://blogs.webtide.com/gregw/2006/07/25/1153845234453.html

The current Apache and Tomcat model of 1 request - 1 thread is quite antiquated

Both Apache [HTTP Server] and [Apache] Tomcat allow using pollers / sendfile / and other techiniques which allow worker threads to focus on processing business logic rather than blocking on IO or serving static files.

For Apache Tomcat, you should look at this documentation: http://tomcat.apache.org/tomcat-6.0-doc/aio.html

http://blogs.webtide.com/gregw/2006/07/25/1153845234453.html

http://www.artima.com/lejava/articles/continuations.html

One thing I have been wondering about is: How is ThreadLocal usage affected by continuations. ThreadLocals are used in lots of places to handle for instance Hibernate sessions and similar request (thread) scoped objects that needs to be reused during a request (thread).

One thing I have been wondering about is: How is ThreadLocal usage affected by continuations. ThreadLocals are used in lots of places to handle for instance Hibernate sessions and similar request (thread) scoped objects that needs to be reused during a request (thread).

For such asynchronously processed requests, ThreadLocals may only be used for each event callback. So each such callback may trigger its own short transaction but not keep a transaction open beyond the current event callback. Existing transaction demarcation mechanisms do not have to change for that, since they operate on synchronous invocations only, which means they can only be applied to each event callback individually anyway. This basically also applies to resources like Hibernate Sessions, so Open-Session-in-View and similar patterns are not applicable anymore. Keeping an extended JPA EntityManager in a request-scoped object would work for an entire request (analogous to an extended EntityManager in a session), although each event callback would still have to operate within its own database transaction (analogous to an extended EntityManager in a session as well). Juergen

That page says this: "IMPORTANT NOTE: Usage of these features requires using the APR or NIO HTTP connectors. The classic java.io HTTP connector and the AJP connectors do not support them." Does that mean that running with that config does not support fronting Tomcat with Apache using mod_jk since mod_jk uses AJP connectors? Thanks.

That page says this:
"IMPORTANT NOTE: Usage of these features requires using the APR or NIO HTTP connectors. The classic java.io HTTP connector and the AJP connectors do not support them."

Does that mean that running with that config does not support fronting Tomcat with Apache using mod_jk since mod_jk uses AJP connectors?

Thanks.

I think http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html will answer your question.

Are there any plans to make Tomcat be able to use non-blocking IO (such as Java NIO), and be able to multiplex several client connection over a small number of worker threads?

Tomcat 6 (well even Tomcat 5.5) has Tomcat Native Connector based on Apache Portable Runtime (APR) that even goes beyond the technical capabilities of NIO and offers thread-per-request model instead traditional thread-per-connection.

Is Tomcat 6 support (with Java EE 5 option for Web projects) planed for NetBeans 5.5.1 or as NetBeans update? Nebojsa

A lot of people benefit from the work of current and past Tomcat developers and others who contribute. Thank you to all the devs, other contributors, and people who submit bug reports. Tomcat works pretty darn well for me!

http://weblogs.java.net/blog/jfarcand/archive/2005/06/grizzly_an_http.html