Re: [javagroups-users] MessageDispatcher and threading in unicast vs. multicast

[Bela B. <be...@ya...>]

Frode E. Moe wrote:

> First of all, JavaGroups looks really cool!

Thanks !

> As I have understood, a messagedispatcher's handle() is never called
> "simulatenously" by two or more threads; only one thread can
> act on handle() at a time. (Am I correct?)


Yes.

> I poked around in 'UDP.java' and it seems there are
> two threads receiving messages, one for multicast udp packets
> and another for unicast udp packets. How can I guarantee
> that handle() is not called simulatenously by the unicast
> and the multicast handler? Or is that taken care of by
> layers further up in the stack? Or will "use_packet_handler"
> take care of this?


handleIncomingUdpPacket() calls passUp(), which eventually will call 
up_queue.add(), which is synchronized by a mutex.

> I am writing an application where a subset of the channel
> members are communicating updates, and another member may want
> to join. I need to ensure that the existing members are not about
> to send updates to the "old" destination list while the new member "joins"
> by sending a "i-want-to-receive-your-subset-groups-updates" (a kind of
> "join" message), unless the new member receives them.


Hmm, sounds like you want to have virtual synchrony in your stack.

As an alternative you could always have your own version number. When 
you subscribe to a group you also get the new version number 
(incremented by 1). Unless you (a) have a version number, and (b) it is 
the same as the one shipped with a message, you discard messages.

> I was thinking of doing this by having the first subset member act
> as a coordinator, and having the other members send a "update request"
> to the coordinator, which then sends "update!" notifications
> back to all the other members if the update request is valid (i.e. it 
> would
> refuse all but the first update request if they have the same serial,
> which means multiple members have concurrently sent update messages).


This would work too.

> Can I count on FIFO ordering and one-thread-at-a-time-in-handle()
> semantics to ensure that the "join" from
> the new member gets processed "in order", so that update requests
> to the coordinator either arrives and is processed fully before
> the new member sends its "join"-message, and update requests
> that arrive while the coordinator is processing the "join" message
> are queued and is handled() after the "join" message (and thus
> sent to the new subset member also)?


Yes you can.

> The subset membership lists is held as group state, using
> the STATE_TRANSFER protocol, and only the _channel_ coordinator
> receives "join" requests for subgroups (even if it not a member
> of the subgroup in question), processes these and broadcasts
> subgroup membership state updates to all channel members. (which again
> due to serialized handle()-ing ensures proper order of "join"
> requests.) This subgroup membership state update acts as a "join"
> request for the subgroup leader, as mentioned above.
>
> I hope all this makes sense :) I've been thinking this through
> over and over, and I believe that as long as handle()s are
> processed one at a time, I think it would work.


This will work.

> (By the way, I'm using the 'vsync.xml' protocol stack definition from 
> the 2.0.6
> release of JavaGroups.)


Since you're doing this yourself in app-space, you don't necessarily 
need vsync. You could use default which is faster.

-- 
Bela Ban
http://www.javagroups.com
Cell: (408) 316-4459