ISPN-4024 Cross-Site State transfer #2392
Conversation
|
Assigning to @danberindei who's very familiar with all the ins and outs of state transfer. |
|
@pruivo please rebase, I'm getting a conflict when rebasing locally. |
| public class XSiteStateTransferConfiguration { | ||
|
|
||
| private final int chunkSize; | ||
| private final long timeout; |
There was a problem hiding this comment.
Shouldn't we have an enabled flag as well?
There was a problem hiding this comment.
no, because the state transfer is only trigger manually by a sysadmin via JMX.
|
PR updated |
| } | ||
|
|
||
| protected boolean isFromStateTransfer(FlagAffectedCommand command) { | ||
| return stateConsumer != null && command.hasFlag(Flag.PUT_FOR_STATE_TRANSFER); | ||
| private boolean isClearKeys(InvocationContext ctx, FlagAffectedCommand command) { |
| * make clear invoke datacontainer.clear() (problem: no locks acquired) | ||
| * block operations in the remote site until all state is received (problem: bad... really bad...) | ||
|
|
||
| isn't happen in NBST? |
There was a problem hiding this comment.
Sanne started a discussion around the semantics of clear on the dev list, but I couldn't find any issue in JIRA. Could you create an issue?
I don't think the problem with clear() is restricted to state transfer, though. Even in a regular, stable cluster, executing a put(k, v) operation at the same time as a clear() operation could result in the key being inserted on some of the owners but not all. And I'm not sure even a global lock would help with that...
There was a problem hiding this comment.
hmmm agree with you that the clear() can cause problems in a normal operation. but why do you think a global lock will not help? if we use a share/exclusive global lock, in which the clear acquires it exclusively, then we make sure that we have no operation interacting with the cache and it is safe to clear
There was a problem hiding this comment.
hmmm, I think I see why the global lock will not work either :(
There was a problem hiding this comment.
JIRA created! https://issues.jboss.org/browse/ISPN-4073
|
@pruivo I'm ok with the new CommitManager, the only part that I'm not 100% ok with is the Collector. |
Cross-Site Replication State Transfer in a stable topology, i.e. no nodes leaving or joining during the state transfer.
|
PR updated! |
|
Integrated, thanks Pedro! |
ISPN-4024 Cross-Site State transfer: alpha version
https://issues.jboss.org/browse/ISPN-4024
Alpha version to review!!
This PR depends of:
Since it add new configuration parameters it would also depend of (note I didn't create a 7.0 parser but instead I changed the 6.0 parser because the configuration will be changed anyway):
The documentation update is included in this PR.