1 Reply Latest reply on Mar 13, 2006 1:55 PM by Manik Surtani

    Refactor jbosscache to provide an interface for transport (I

    Nick Betteridge Newbie

      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.