[
https://issues.jboss.org/browse/ISPN-835?page=com.atlassian.jira.plugin.s...
]
Galder Zamarreño commented on ISPN-835:
---------------------------------------
Hmmm, so what you're suggesting is that instead of the sender keeping track of the
pending prepares/writes, let the joiners receive and queue these prepares and then apply
them when state transfer has completed?
How would these prepares/writes be sent to the nodes? Via the state transfer synch path,
or the potentially async channel? I'd imagine it'd be the first, otherwise
you'd be back to the same problem?
What about the joiner flag? I suppose you discarded that option. Why exactly?
State transfer should not force all invocations to be synchronous
-----------------------------------------------------------------
Key: ISPN-835
URL:
https://issues.jboss.org/browse/ISPN-835
Project: Infinispan
Issue Type: Bug
Components: RPC, State transfer
Affects Versions: 4.1.0.Final, 4.2.0.CR4
Reporter: Galder Zamarreño
Assignee: Manik Surtani
Priority: Critical
Fix For: 4.2.1.Final, 5.0.0.BETA1, 5.0.0.Final
Enabling state transfer is forcing even asynchronous caches to become synchronous.
A better way is needed to make sure state transfer works correctly (sync calls needed
here) while normal replication calls remain asynchronous.
See
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
where the response mode is overridden based on whether replay is supported. And replay
support is always on when state transfer is enabled:
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
Need to explore whether a joiner flag can be maintained based on a view change, and
replay only supported when a joiner is still "joining", and not otherwise.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira