SEDA, or staged event driven architecture was all the rage about four years ago. (http://www.eecs.harvard.edu/~mdw/proj/seda/).
Java 1.4 added the NIO, or “new IO” package inspired by it.
The logical next step was a Java web server using the approach. I spent some time last week tuning our Glassfish application server for production. The default is 10 threads. In Orion we can peak at around 500 and have at times used over a 1000. So I was scratching my head, and then I realised that Grizzly has a connection pool with defaults in the thousands but only 10 worker threads. Connections enter a queue and then get serviced. SEDA.
In the end I decided to set the number of worker threads to the number of connections in the database connection pool (75) plus 25 threads for service from cache. Ehcache is pretty fast, so we can have a small thread pool to service requests purely from cache.
As someone with a reasonably long memory I thought it appropriate to acknowledge SEDA and reflect on its appearance in a mainstream Java application server.