Sorry for the late response on this thread.
I think solution #2 is overkill - this could be a huge bottleneck. Something like
solution #1 will work, but that's still expensive (in terms of memory consumption, and
consequently GC).
Are the communications between relay coordinators (RC) asynchronous? I realise the
communication is not on the critical path of a transaction in either data centre, but it
could still be sync. If this were the case, we could have something like this:
Assume {A, B, C} and {X, Y, Z}. A --> X synchronously, but offline (in a separate
thread) so calling transactions aren't blocked. Assume key K is on {A, B, Z}. A
change to K would synchronously update A and B, and put the update on the RC (and backup
RC)'s processing queue. A then flushes to X, and on receiving the ack from X, informs
B that the message was delivered. If X crashes/doesn't ack, A keeps retrying,
potentially batching queued updates.
WDYT?
Cheers
Manik
On 14 Dec 2011, at 11:51, Bela Ban wrote:
Tobias made me aware of a bug that can happen when we use RELAY and
one
of the relay coordinators crash: messages sent between the crash of the
relay coordinator and the switch of the backup relay to full relay are
not relayed.
This can lead to inconsistencies, see [1] for details. If I implement
solution #1, then the chances of this happening are vastly reduced.
I wanted to ask the bright folks on this list though, if you see a
solution that only involves Infinispan (rebalancing) ?
Cheers,
[1]
https://issues.jboss.org/browse/JGRP-1401
--
Bela Ban
Lead JGroups (
http://www.jgroups.org)
JBoss / Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org