Re: [jgroups-dev] First view change and JChannel.connected

I don't think that would work, because threads calling into user space 
could race, potentially passing each other. Also, currently we guarantee 
that viewAccepted() is never called concurrently, and breaking this 
might also break some user code...

But what if we only used *one* single thread to do that ? The thread 
would read view changes off of a queue, to which the interval 
view-change message adds ? This way, we'd have correct ordering, and no 
concurrent invocations...

Hmm, still, I don't really like this, because that's another additional 
thread that we'd have to introduce...


Oops, scrap that ! It won't work: if we get messages A2 --> A3 --> A4, 
and A3 is the view, then everybody needs to deliver messages 2-4 from A 
in that order. If we now delivered A3 on a separate thread, then that 
ordering could be destroyed !

If an application - when it gets the view in A3 - decides to handle it 
on a separate thread, then it's the app's responsibility and it needs to 
know that A4 could be delivered before the view handling code has 
returned...

OK, so I changed the code below to actually changed a channel to 
'connected' when it gets a view and is still unconnected. However, I 
also added a note in the documentation [1] to warn about sending 
messages from a callback.

WDYT ?

[1] http://jgroups.org/manual/html/user-channel.html#MembershipListener


On 11/23/10 2:27 AM, Vladimir Blagojevic wrote:
> What if we reserve thread carrying a view to only modify internal
> JGroups structures while we notify client on another thread from the
> pool? That way we could guarantee proper client view notification
> with/without FLUSH installed and client can freely send messages from a
> callback without affecting anyone.
>
> On 10-11-22 6:06 AM, Bela Ban wrote:
>> In JChannel.up() [line 1349], we have a comment which says that a
>> channel can only be connected after JChannel.connect() returned.
>>
>> So the first view change received by a node won't be able to send a
>> message because the channel is still disconnected. However, subsequent
>> view changes will be able to send messages.
>>
>> I don't like this as it is not symmetrical: if someone gets a view
>> change with itself as member of the view, it should be able to send
>> messages.
>>
>> I changed JChannel.up() and uncommented lines 1356ff, when a view
>> change is received, then connected is set to true.
>>
>> Do you see any adverse effects of this ? The test suite passes, except
>> for the 2 tests which explicitly test this behavior (I changed that,
>> so they pass now).


-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Javagroups-development mailing list