[jbosscache-dev] Shared transport in AS
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 'tunnel'
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