Buddy Replication

Buddy replication - the ability to replicate your HTTP or SFSB session data to specific servers in a cluster and not to everyone - is a feature that is WIP in JBossCache at the moment, and will probably not be ready for production use till the summer of 2006.  That said, the goals of buddy replication could still be achieved with the new features in JBossCache 1.3 - the underpinning technology used by JBoss session replication.

Let us analyse the goals of buddy replication.  Buddy replication is used:

1. to achieve failover by ensuring that collective state of a cluster is maintained even if some servers in a cluster go down.

2. to minimise network traffic that is a result of full replication of state to all servers in a cluster.

3. to minimise memory usage which is a result of each server maintaining not only its own state but the state of every server in the cluster.

Until we have a production-ready buddy replication implementation, there are some interesting new features in the upcoming JBossCache 1.3 that can be used to achieve similar results.

JBossCache 1.3.0 (due for release in March 2006)

Some new features in JBossCache 1.3.0 that we could use:

• Chaining Cache Loader.  This feature allows you to configure more than one cache loader.

• ClusterCacheLoader.  This cache loader queries in-memory state of other caches in the cluster, behaving as a cache loader.

• New cache mode - INVALIDATION rather than REPLICATION - so that when a node is updated, rather than replicating data, other caches receive an invalidation message to evict the node in memory.  This way we can notify other caches in a cluster of an update without needing to replicate the changed objects.

Using these features to achieve the effects of Buddy Replication

1. To achieve durability of persistent data:

• A chaining cache loader should be configured with a ClusteredCacheLoader and a JDBCCacheLoader.

• Use the ClusteredCacheLoader to quickly retrieve data from other caches in the cluster.

• Should be tuned with sensible timeouts.

• Use the JDBCCacheLoader as the 'true' representation of all state in the system.

• Should be shared so all servers use the same JDBCCacheLoader

2. To minimise network traffic:

• If a cache cluster were configured with invalidation rather than replication, we have effectively minimised network load.

3. To minimise memory usage on cluster nodes:

• Since data is not replicated to all servers in the cluster, all servers don't maintain all session data in the cluster.

• The caches should be tuned with a sensible eviction policy

This does not mean we're NOT doing Buddy Replication!

Alternatives are always good, but just because we have one does not mean we will not be adding production-grade buddy replication to JBossCache in the very near future.  Watch this space, but in the meanwhile, if you run a cluster of a large number of servers and want to achieve some of the goals of buddy replication, consider tuning JBossCache 1.3.0 as described above.

Buddy replication is targeted for release in JBoss Cache 1.4.0 "Jalapeno", by the end of April 2006.  See JBossCacheBuddyReplicationDesign for an idea of what to expect.

Sample configuration files

See optimal-for-large-cluster-http-session-repl.xml in the /etc/META-INF directory of the JBossCache CVS tree.