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