[infinispan-dev] Distribution across multiple sites

[Manik Surtani]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org