Refactor jbosscache to provide an interface for transport (I

[aubergine]

This is just to initiate a discussion on the best way to incorporate a transport mechanism into JBossCache - ie. provide a mechanism for providing transports between caches other than JGroups.

One of the main reasons for undertaking this is that we have a number of projects using jboss remoting and use instances of an old, modified version of jboss cache - some of the projects use a number of different remoting transports, and as a consequence the transport is transparent to jboss cache. Most of the projects are unable to use jgroups as they have to run on existing frameworks where straightforward ip addressing is unavailable (hence the use of jboss remoting).

My original idea was to refactor jbosscache and introduce an interface similar to that of hedera (http://hedera.continuent.org) - Hedera is targeted at reliable group communication within clusters and their default implementation is JGroups. Adding another transport is relatively easy.

After bouncing this off Bela and Manik it seems that an easier approach would be to do a simpler refactoring and move JChannel from TreeCache to ReplicationInterceptor.

Manik then came back with the following as a way to move forward ...

1. Move all network related configurations and operations relating to remote caches to the BaseRPCInterceptor (this interceptor does not exist in 1.2.4, only in CVS HEAD)
2. The ReplicationInterceptor extends BaseRPCInterceptor anyway so it will still have access to remote caches
3. Other network related code (e.g., state transfers) should be moved to the replication interceptor rather than the TreeCache.

So, does anyone else have any inputs about this? I would like to try and move forward on this as soon as possible.

Cheers
Nick

[manik]

Hi Nick.

There hasn't been much interest in such a feature (http://jira.jboss.com/jira/browse/JBCACHE-311), and as such, I'm not very keen on increasing prio on this one. It would be a ncie to have, but at the moment a lot of the internal code relies on JGroups. The channel is one example, but all invoke() calls on the interceptors take in JGroups MethodCall objects.

There are plans to move away from MethodCalls and reduce the dependency on JGroups - such as http://jira.jboss.com/jira/browse/JBCACHE-468 and http://jira.jboss.com/jira/browse/JBCACHE-198 - and these will have to be done before we can consider making JGroups an optional transport. That said, even these plans are not high priority and a bext guess on some of these would be around Q3 this year.

I appreciate your situation and your inability to use JGroups for whatever reason, but given the current workload and feature list on our plate, I don't realistically see JBCACHE-311 happening very soon.

Cheers,
Manik