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(a)redhat.com