Abstraction of JGroups (JBCACHE-311)
brian.stansberry Apr 24, 2006 2:51 PMDiscussions related to http://jira.jboss.com/jira/browse/JBCACHE-311 following more IM chats between Manik and myself.
JBCACHE-311 proposes creating an abstraction separating JGroups from JBossCache. This was scheduled for 2.1, although some or all of the work may make sense for 2.0.
Some initial thoughts:
1) The JIRA mentions moving the JChannel stuff to the ReplicationInterceptor. However, state transfer in all its many flavors also needs to use the channel. Manik and I have discussed this and passing the state transfer related calls through the interceptors doesn't really fit well (e.g. replication is a push operation; state transfer is a pull). However, we'd like to simplify the TreeCache implementation class by removing the callRemoteMethods() stuff.
We were discussing creating an "RpcManager" to provide the RPC call functionality for both ReplicationInterceptor and state transfer. The TreeCache impl would be responsible for creating the RpcManager and making a ref to it available to interceptors and the state transfer code.
This RpcManager (probably renamed) is a logical portion of the JBCACHE-311 abstraction.
If we create RpcManager, we shouldn't use JGroups' MethodCall in its API; instead use JBC's own abstraction of a MethodCall.
2) Multiplexer integration is going to involve changes to the way the JChannel is configured/managed. It makes sense to consider JBCACHE-311 when we design the multiplexer integration. E.g. encapsulate all transport related config in an element that can be passed to a user specified "TransportManager" class (not really trying to think of good names here). The JGroupsTransportManager knows how to parse the config to either use the multiplexer or create a JChannel the old fashioned way.
Presumably this "TransportManager" and the previously mentioned "RpcManager" would be the same thing; need to sort out names.
3) Finally, there is the JGroups MembershipListener side of things. This includes abstracting away the MembershipListener interface, as well as direct use of Address/IpAddress.
A major concern is doing this for 2.0 is a lot of work, but OTOH when we create the multiplexer integration seems like the logical time to do it.