[infinispan-dev] xsite state transfer design

[Mircea Markus]

On 2 Oct 2012, at 20:23, Erik Salter wrote:

> 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?
AFAIK it has to, but it is not required that all nodes to be primary owners for a segment. Dan/Adrian can confirm.
> -        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?
There's no 1 push per key, but they are batched  up to "stateTransferCheckSize" and sent only at that point: https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/statetransfer/OutboundTransferTask.java#L217
> -        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?
not sure I get your question… the tombstone refers to entries within the data container and not tx  in the table. I also think that they will be implemented at data container level and not within an interceptor.   
> -        What do you mean by “BackupInterceptors replicate the operations to the remote site as well”?  Are you referring to the normal operation of XSite?
yes
> -        If a key fails to replicate, do you see any danger in another pushState(site, key) command?
a more specialised push that would only send a subset of the keys? I don't think that's a problem but it might also make sense to do a retry *during the state transfer itself* a number of times (100?).
> -        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.
ATM the BackupReceiver.remote2localTx is not backed up, but only leaves on one coordinator. I'm not even sure it can be backed up on another node, as it contains javax.transaction.Transaction objects. This is a tricky problem but we can always default to the optimistic approach for a start: restart the state transfer. 
> 
>  
> 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_Transfer_between_sites 
>  
>  
> Cheers,
> -- 
> Mircea Markus
> Infinispan lead (www.infinispan.org)
>  
>  
> 
>  
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20121003/2991e986/attachment-0001.html