[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