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

OK. Why an AtomicReference; wouldn't a simple Object do ?

Brian Stansberry wrote:
> 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.
>
>   

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss


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