2.2.0 "Poblano" and the evolution of JBoss Cache

So we've finally cut JBoss Cache 2.2.0.Beta1. This is meant to be a minor release on 2.1.0, with some new features (JBCACHE-1258 and JBCACHE-1320 - both involving better cleanup of buddy backup regions when buddy groups no longer exist or when data is gravitated away), and some bug fixes and minor enhancements. And, pretty severe internal refactoring.

Before I bore you with details, here's a summary. The refactoring has provided us with a much more flexible architecture, where everything is far easier to extend, build upon and unit test, and in the process we've gained on average a 15% performance increase over 2.1.0, based on your cache mode. Enough said. :-) Read on for gory details, or skip to the bottom for benchmarks download links and the like.

Now the gory details. The original architecture of JBoss Cache involved a CacheImpl class, which contained most of the core functionality, and a series of interceptors which added aspects such as replication, cache loading and locking among others. Invocations were made on CacheImpl (exposed via a Cache interface), which created an invocation object - a subclass of JGroups' MethodCall object - and passed it up the interceptor chain. The final interceptor would then invoke an internal method on CacheImpl via reflection.

This gradually simplified (in 2.1.0, Alegrias) to use a separate delegate class which implemented the Cache interface, which pushed an invocation up the interceptor chain to end up as an invocation on the CacheImpl, as well as a ComponentRegistry which managed lifecycle and dependencies between different components in the cache such as the BuddyManager, RPCManager, NodeFactory, Notifier, etc. and inject these into interceptors that declare their dependencies on such components. This made things a lot more flexible and extensible, necessary to develop the host of new features we have planned for upcoming releases.

With Poblano, we've implemented a design by Mircea Markus, which uses Command/Visitor pattern and double dispatch to achieve strongly typed callbacks into interceptors. This involves scrapping the CacheImpl altogether, and implementing each public API method as a VisitableCommand. VisitableCommands can be visited by interceptors (which now implement Visitor), each visitXXX() method on each interceptor receiving a strongly typed VisitableCommand implementation with strongly typed payloads and parameters. The final interceptor - the CallInterceptor - now simply invokes VisitableCommand.perform(). Commands also have all the knowledge they need on how to roll back, via a rollback() method, which removes the need for an undo log for each transaction. The modification list is adequate for performing rollbacks as well.

Apart from the minor gains in stronger type safety (no more casting of MethodCall arguments) and doing away with the need for reflection in the CallInterceptor, the primary benefit of this approach is much better code readability, maintainability and unit testability (how many "-ity"s can you use on once sentence?!). Interceptors and commands alike can now be isolated and unit tested, rather than end-to-end functional tests for every combination of configurations, and the overall architecture is much easier to work with when adding features.

In terms of backward compatibility, even with the new architecture this release is 100% compatible with other 2.X releases, in terms of wire protocol (a 2.2.0 cache instance can talk to a 2.1.0 one, thanks to a new Marshaller implementation that is aware of and can translate between commands and MethodCalls being replicated) as well as in terms of plugins and extensions. Custom interceptors extending the abstract (and now deprecated) Interceptor class will still work, although the preferred approach now is to extend CommandInterceptor and use the strongly typed callbacks.

And now for the big surprise - as I said before, the real goal behind this was to improve the architecture for ease of use, robustness and maintainability, and as long as we didn't regress in terms of performance, I would have been quite happy with things. After the last week benchmarking and profiling things, we've had a very pleasant surprise, with pretty interesting performance gains. I'll let the numbers speak for themselves - Mircea has published his benchmark numbers here, on this wiki page, along with extensive information on how the test was run. Along with pretty charts. We all like pretty charts. :-)

So Poblano is now available as a beta, and I would very strongly encourage everyone to download and try this out. We want to make sure this release works as well for everyone as we hope it will. Check out the release notes, userguide and javadocs and benchmarks while you download the release, and comment and feedback on the user forums!

Enjoy!
Manik