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@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.