[infinispan-dev] xsite state transfer design

[Erik Salter]

Hi Mircea,

 

Awesome, thanks!

 

Initial questions:

 

-        Calculate a minimal set of nodes that can generate state:  So the
state provider doesn't have to be the primary owner?

-        We are sequentially pushing each key. I presume we can leverage the
xsite implementation to send (and manage) these keys in an executor (and
manage the Future<?> this way)?   This way, any monitoring of keys knows
that they've been successfully pushed.  Also, any thought into batching this
operation?

-        For the tombstone functionality, I thought this might be
implemented as an interceptor (with an "invoked" flag).  In this case,
wouldn't we know what's been removed and put it into the
BackupReceiver.remote2localTx map accordingly?

-        What do you mean by "BackupInterceptors replicate the operations to
the remote site as well"?  Are you referring to the normal operation of
XSite?

-        If a key fails to replicate, do you see any danger in another
pushState(site, key) command?

-        Error handling:  We know there are some JGroups options/protocols
to mitigate the remote xsite coordinator dying.  In addition to that, the
obvious case is an abort command.  My thinking is that it would leverage
some of the existing policy (like site "DOWN") and automatically abort with
an error code.

 

Thanks,

Erik

 

From: infinispan-dev-bounces at lists.jboss.org
[mailto:infinispan-dev-bounces at lists.jboss.org] On Behalf Of Mircea Markus
Sent: Tuesday, October 02, 2012 12:58 PM
To: infinispan
Subject: [infinispan-dev] xsite state transfer design

 

Hi,

 

After discussing with Dan and Adrian, I've updated the xsite state transfer
document with a suggested design[1].

Note that this is out of scope for 5.2. Any review is very welcomed.

 

[1]
https://community.jboss.org/wiki/DesignForCrossSiteReplication#State_Transfe
r_between_sites 

 

 

Cheers,

-- 
Mircea Markus

Infinispan lead (www.infinispan.org)

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20121002/c856fbe1/attachment.html