[jbosscache-dev] Shared transport in AS

[Brian Stansberry]

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 at redhat.com