[jbosscache-dev] JGroups Shared Transport support in JBC

[Brian Stansberry]

In JGroups 2.6.2, the JGroups team is introducing the shared transport 
as a (superior) alternative to the multiplexer.  Want to touch off a 
discussion of how to take advantage of that in JBC.

Currently in JBC, user can inject a ChannelFactory into their cache 
configuration, and configure a MultiplexerStack (string).  If both are 
set, JBC calls ChannelFactory.createMultiplexerChannel(), which returns 
a MuxChannel.

So, how can JBC get a regular JChannel w/ a shared transport instead of 
a MuxChannel?  Couple solutions come to mind:

1) Add a configuration property ChannelStack to the JBC config.  If 
present, JBC calls JChannelFactory.createChannel(String) instead of 
ChannelFactory.createMultiplexerChannel().  Basically, the user 
indicates what they want by how they configure.  This IMHO is the 
cleanest and simplest.

Problem is the createChannel(String) method is not exposed in the 
ChannelFactory interface; it's only in the JChannelFactory 
implementation.  JBC needs to use the interface.  Bela, can this method 
be added to the interface in 2.6.2?

If it can be, any thoughts switching JBC 2.1 to use 2.6.2 and adding the 
property?[1]

2) A hackier alternative is to override the behavior of 
createMulitiplexerChannel so it checks the specified protocol stack 
config and returns a regular JChannel if the stack uses a shared 
transport; a MuxChannel otherwise. AS 5 already uses a custom 
ChannelFactory impl (for other reasons); doing this is how I plan to get 
shared transport support in AS 5.  I suppose doing the same thing in the 
standard org.jgroups.JChannelFactory class is possible, although I don't 
advocate it at all; it seems hacky.  Better IMO to adapt channel factory 
users to call the correct method.


[1] Note that the hacky #2 approach is very likely to remain in AS 5 
since JBM has the same usage as current JBC. So, getting this in JBC 2.1 
is not a requirement for AS 5, just a "nice to have", something that if 
done now can avoid future compatibility issues, etc.

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com