Been playing with using the 2.6 branch version of the shared transport in JBoss AS. Unfortunately, the dead-simple integration approach I was thinking of is not valid. (See http://jira.jboss.com/jira/browse/JBAS-5167). I've got other ideas I'm playing with; I'm sure I can come up with something; won't get into details of the problem here. But, aside from a few failures related to the flaw in JBAS-5167, it looks like the AS testsuite ran well w/ shared transport channels used instead of multiplexed ones. :) There are a few things I saw that IMHO need improvement before we can switch the AS to this: 1) TP.members -- used to send to all members via unicast by TCP (or by UDP if multicast is disabled). AIUI this should probably be a Map<String, List<Address>> so separate memberships can be maintained. 2) MPING. We'd discussed having MPING drop GET_MBRS_RSP messages that are not associated with the channel's group name. This allows a single MPING config (i.e. mcast_addr, mcast_port) in a stack to be instantiated multiple times, for different channels. AFAICT, the way it is now, 2 channels created from the same stack will see each others' ping requests and respond, with the irrelevant responses from the wrong channel being treated as valid. That's a pretty small list. I really like this stuff; excellent work, guys!! Something else that seems *much* less a show-stopper but is still a concern: The shared transports are stored in a VM-singleton map -- ProtocolStack.shared_transports. Can these instead be stored as an instance field in JChannelFactory? This makes the scope of sharing controllable. Perhaps this could be a flag on the JChannelFactory; use the VM-singleton map by default but use a factory-scoped map if a flag is set. This bit me in one unit test where I deliberately create 2 JChannelFactory instances to simulate two cluster nodes. Each factory creates two channels (were multiplexed, now shared TP). Then I do some manipulations. This test fails because when I create the channels from the 2nd factory, Configurator.startProtocolStack barfs: Caused by: java.lang.IllegalStateException: cluster &apos;tunnel&apos; is already connected to singleton transport: [tunnel, dummy-1201128933100] at org.jgroups.stack.Configurator.startProtocolStack(Configurator.java:88) at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:316) at org.jgroups.JChannel.startStack(JChannel.java:1442) ... 28 more With the channels stored in a static map, there's no clean way to simulate two separate environments. I imagine this kind of scenario would be common in test cases; I believe JBC has some similar kinds of tests. -- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat brian.stansberry(a)redhat.com