[jgroups-dev] Improvements in org.jgroups.blocks.mux

Brian Stansberry <[email protected]>
Newsgroups gmane.comp.java.javagroups.devel
Message-ID <[email protected]>
I've been working on switching the JBoss AS clustering code to work off 
a MuxRpcDispatcher to see where any pain points are.[1]  So far what I'm 
seeing is:

1) MuxRequestCorrelator needs to override the sendUnicastRequest() 
method. Simple fix, already done; see [2].

2) MuxUpHandler needs to handle more event types.  This really comes 
down to 2 cases:

a) misc events that need to be passed to all up handlers, which is simple
b) state transfer

I've gotten a state transfer solution working. See patch attached to [3].

It's based on a rule that if a bunch of components of a service want to 
share a channel via MuxRpcDispatcher, then at most one can use full 
state transfer; the rest must use partial state transfer. Those that use 
partial state transfer can register an UpHandler with the Muxer that 
implements a new StateTranferFilter interface

boolean accepts(String state_id)

MuxUpHandler handles state transfer related events by iterating through 
the registered handlers, calling accepts(), passing the event to the one 
that returns true, with fallback logic if none accept. See patch at [3] 
for further details.

I think the design requirement here that all but one component must use 
partial state transfer and must provide a StateTransferFilter is OK.
Unlike the earlier MuxChannel or the shared transport, MuxRpcDispatcher 
is not intended for general multiplexing of completely unrelated 
services where the service developers may know nothing about each other. 
  The use case for MuxRpcDispatcher is a set of *components of a larger 
overall service* that need to send RPCs over the same channel. The 
person developing that overall service (e.g. me) can be expected to have 
an understanding of how the service's components work and how they are 
multiplexing over the channel.

3) The integration with services like JBC that aren't written to use the 
MuxRpcDispatcher can be made easier with some fairly simple changes to 
Muxer/MuxUpHandler/MessageDispatcher. See patch attached to [4].

Basically the patch seeks to formalize a bit the concept of a default 
UpHandler.

4) NoMuxHandlerRspFilter can't be used because it will return 'false' 
from isAcceptable(). See [5] for discussion of why that is not reliable. 
Upshot is users of MuxRpcDispatcher need to deal with NoMuxHandler 
responses.

- Brian

[1] The key reason for doing this is to aid in Infinispan integration by 
supporting https://jira.jboss.org/jira/browse/JBAS-7852 . But for my 
initial work I'm converting the AS HAPartition impl to use a 
MuxRpcDispatcher to share a JGroups Channel with the JBoss Cache 
instance used by HAPartition's "DistributedState" component. Doing this 
first lets me expose issues more easily since the large set of 
HAPartition use cases and associated tests have to work.

[2] https://jira.jboss.org/browse/JGRP-1208

[3] https://jira.jboss.org/browse/JGRP-1209

[4] https://jira.jboss.org/browse/JGRP-1210

[5] http://old.nabble.com/Race-condition-with-RspFilter-td28261345.html

-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Javagroups-development mailing list
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.