ehcache-1.2.4 released

Ehcache-1.2.4 has been released.
It contains four feature and fifteen bug fixes received in the three months since ehcache-1.2.3 was released. See the changelog for details.
Eight of the changes in this release are scalability improvements contributed by users running very large ehcache deployments. The distributed caching changes stem from a user who is using ehcache in a multi-subnet cluster of 20 nodes.
The Caching and Gzip filters in the web package have been updated to work on Glassfish and Tomcat.
The distributed caching functionality in ehcache is now 6 months ago and is widely used. Moreover the maintainer has now been running ehcache distributed in production for four months without incident. This functionality can now be considered mature.
Another area that has improved in this release is a large reduction in thread use. Ehcache used to use three threads per DiskStore. Now it uses one.
Ehcache has no open bugs or patches at the time of release.
Work now turns to a meaningful JSR107 (JCACHE) implementation and perhaps pushing to fix up and then releasing JSR107. From what I have seen around there is now pent up demand for JSR107 to be released. I am planning to implement it as it is but keep a list of its shortcomings for use in negotiating some improvements with my expert group colleagues.

SEDA, NIO and Grizzly/Glassfish

SEDA, or staged event driven architecture was all the rage about four years ago. (
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.