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

On 06/07/2010 04:03 PM, Brian Stansberry wrote:
> On 06/07/2010 02:49 AM, Bela Ban wrote:

>> If that's the case, I'd say pass all state related calls to the default
>> handler and throw an exception if a non default handler does state.
>>
>
> HAPartition exposes a state transfer API to outside callers, and some
> internal HAPartition components use it (i.e. DRM). But yeah, I agree,
> with your general architectural point.
>
> The other thing is, the JGroups API exposes hooks (i.e. Muxer and
> UpHandler are both interfaces) such that I can plug in
> StateTransferFilter et al as AS-specific HAPartition behavior that
> doesn't need to be in JGroups.
>

I think a simple solution is to add this method to MuxUpHandler:

/**
  * Extension point for subclasses called by up() when an event
  * related to state transfer is received, allowing the subclass
  * to override the default behavior of passing the event to the
  * default up handler.
  *
  * @return true if the event was handled and no further processing
  *         should be done in up(), false if up() needs to handle
  *         the event. This default implementation always returns false
  */
protected boolean handleStateTransferEvent(Event evt) {
     return false;
}

That largely removes the complexity and potential "oops - bad design" 
issue from JGroups. HAPartition has always used a specialized 
RpcDispatcher subclass, so having it override that method is no big 
deal. The complexity is then an internal implementation detail of 
HAPartition.

-- 
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