JBoss Cache and the community

Roberto Tyley, who provided an important fix to JBoss Cache's eviction queue processing code in JBCACHE-1473, has written an excellent article on open source, using the sources, finding, analysing bugs and contributing to the project. He also has an interesting use case for JBoss Cache, using the cache in front of a database on a high-volume site such as The Guardian, a major newspaper here in the UK. I encourage you to have a read, along with Frederik Johansson's article on using JBoss Cache for simulating distributed load for online gaming.

Does anyone else have interesting usage stories they would like to share?

Cheers
Manik

JBoss Cache 3.1.0.BETA1

3.1.0's been somewhat delayed due to problems with Non-blocking State Transfer, but these have finally been overcome.

Here's a quick summary first. The first Beta of JBoss Cache 3.1.0 Cascabel is now available in the usual places (download, docs, forums). The main feature of Cascabel is Non-blocking State Transfer, a new and highly efficient state transfer mechanism. Also, since MVCC was introduced in JBoss Cache 3.0.0 Naga, lock striping was used for the write locks held by nodes. While lock striping is efficient, it always exposes a slight risk of deadlock. In Cascabel, we now offer a lock-per-Fqn option for MVCC, which is more expensive than striped locks but is guaranteed to be deadlock-free. In addition, there are a host of bug fixes across the board, so this is definitely a version you should upgrade to if you use JBoss Cache 3.0.x.

Now for the details, starting with Non-blocking State Transfer (NBST). NBST has certain pre-requisites, specifically, that you use MVCC for locking and that you use JGroups' STREAMING_STATE_TRANSFER protocol. NBST works by allowing state to be read, free of locks thanks to MVCC, streamed to the receiver, all the while allowing the sender to continue changing state. What is key is that the sender also maintains a transaction log for this period. Once the state is delivered to the recipient and applied, the transaction log is then also streamed across, until the transaction log reaches a predetermined, small size - or it is detected that the transaction log grows faster than it can be streamed. In either of these cases, a lock is acquired on all processing, causing the sender to block all new transactions for a short period while the last of the transaction log is streamed and applied. After this, both the sender and receiver release locks and start processing requests, the new joiner now at the same state as the sender.

The main benefit of this approach is that the sender is not blocked for the majority of the time while generating and streaming state (made all the more apparent when there is a lot of state to send) and the cluster proceeds to operate. Naturally, the implementation is a fair deal more complicated than what is described quite simplistically above, with a fair few more details and edge cases to be dealt with. :-)

NBST is disabled by default, but can be enabled by using a simple configuration switch (Configuration.setUseNonBlockingStateTransfer() or <stateretrieval nonblocking="true" />).

So do give it a whirl, feedback, as always, is appreciated.

Cheers
Manik