Re: [jgroups-dev] Inconsistent Channel#getState return semantics between byte and streaming state transfer

[Vladimir B. <vla...@re...>]

Yes I though the same. Will verify it though!

Solution to http://jira.jboss.com/jira/browse/JGRP-619 will revamp 
getState semantics completely and get rid of a need for the additional 
synchronization/lock mumbo jumbo. If you have any ideas or comments on 
that subject - keep them coming!


Brian Stansberry wrote:
> That should be fine. There's been a race between the thread that calls 
> get state and the JGroups thread that sets the state. An app that 
> properly handles state transfer needs to handle that race by doing 
> something like this:
>
> if (ch.getState()) {
>    synchronized(state_tfer_lock) {
>       if (!state_set) {
>          state_tfer_lock.wait();
>       }
>    }
> }
>
> with the setState implementation acquring the lock, setting the 
> state_set flag and notifying anyone waiting on the lock.
>
> You're basically changing things so the setState method is always 
> executed first.  In that case the code above isn't needed but will 
> still work fine; i.e. nothing will break.
>