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: [email protected] > [mailto:[email protected]] 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org)
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
