[infinispan-dev] TOM

Pedro pruivo at gsd.inesc-id.pt
Fri Mar 23 15:53:49 EDT 2012


Hi Bela,

Comments inline.

Cheers,
Pedro

Bela Ban wrote:
> Hi Pedro,
>
> I'm currently looking at your TOM protocol (GROUP_MULTICAST).
>
> I have a couple of points to discuss:
>
> #1 We need to find a better package name for org.jgroups.protocols.pmcast
>
To keep it consistency with the concepts used in JGroups, yes we must find
a new name.

> #2 We also need to find a better name for the protocol GROUP_MULTICAST.
>
>
> In JGroups, we call a message to a single cluster member a *unicast*, a
> message to all cluster members a *multicast* and a message to a subset
> of the cluster members an *anycast*. So I guess both the package name
> and the protocol name should have something to do with "totally ordered"
> and "anycast"...
>
> How about
> - TOA (Total Order Anycast) ?
> - TOPR (Total Order for Partial Replication) ?
> - TOS (Total Order for a Subset) ?
> -
>
> Thoughts / suggestions ?
>

I prefer the first one: TOA.

Another suggestions: Group Total Order, Subset Total Order.

>
> #3 I assume your changes to Infinispan involve sending a 1-phase
> PREPARE/COMMIT message to N members (who own the keys touch by the TX).
> In Infinispan, this is done via (IIRC) N unicasts, or - if this was
> changed in the meantime - by an *anycast*.
>
> Say we have to send the 1PC PREPARE message to {A,C,D,E}. So this would
> be 4 unicasts (to A, C, D and E) or an anycast to the target set
> {A,C,D,E}. The latter will result in 4 unicasts, like the former.
>
> The way we could do that is to have Infinispan pass the target list
> {A,C,D,E} to RpcDispatcher.callRemoteMethods() as targets. Also,
> Infinispan would have to use a new option (e.g.
> use_total_order_anycast). When this flag is set, in
> RequestCorrelator.sendRequest(), we'd create a GroupAddress={A,C,D,E}
> and send a new Message with the GroupAddress as destination down the
> stack.

Yes I have that. Well, actually, I have two flags: totalOrder flag and
distribution flag. The first one was added for TOB so I've just added a
new one for TOM, indicating that the message is in a distributed mode
cache.

You can see the code here [1]. Note that this is my "work in progress"
branch (so it has a lot of commits, merges and it is not very clean) and
it does not have the most recent version of the code.

>
> The new protocol would then see that the Message.dest is a GroupAddress
> and handle the message (not passing it further down, as the other
> protocols can't handle GroupAddresses).

That is true. It does N copies of the message and send them in unicast.

>
> Is this the change you made in your prototype used in the paper
> "Exploiting Total Order Multicast..." to run the benchmarks, comparing
> TOM to 2PC ?

It was done a litle different. I've created a new PrepareCommand and in
CommandAwareRPCDispatcher, it checks for the type of the command to send.
I haven't had any flags like now.

>
> --
> Bela Ban, JGroups lead (http://www.jgroups.org)
>

[1]
https://github.com/pruivo/infinispan/blob/total-order-dist/core/src/main/java/org/infinispan/remoting/transport/jgroups/CommandAwareRpcDispatcher.java#L328



More information about the infinispan-dev mailing list