[
https://issues.jboss.org/browse/ISPN-1910?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-1910:
------------------------------------
I'm not aware for any other logic forcing a sync RPC besides replay support.
After Bela brought up this link I searched a bit and I'm pretty sure that replay is no
longer useful (since we stopped replying with RequestIgnoredResponse or ExtendedResponse).
However, if there is any other logic forcing sync RPCs, we should evaluate it separately.
For instance, StateTransferInProgressExceptions are not thrown when the cache is in async
mode - so there is no need to make all RPCs synchronous in order to catch these
exceptions. But remote CommitCommands can still return RESEND_PREPARE, so if the set of
targets has changed the RPC needs to be synchronous.
I fixed the last sentence and I added 5.1.x as fix version.
State transfer should not force all invocations to be synchronous
-----------------------------------------------------------------
Key: ISPN-1910
URL:
https://issues.jboss.org/browse/ISPN-1910
Project: Infinispan
Issue Type: Bug
Components: RPC
Affects Versions: 5.1.2.FINAL
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 5.1.x, 5.2.0.ALPHA1, 5.2.0.FINAL
This is a reedit of ISPN-835, only now it affects both repl and dist caches as a result
of my ISPN-1475 fix. All invocations are supported because enabling state transfer also
enables replay support, but there is no reason to support replay at the transport level
any more.
Before ISPN-1194, a cache could receive RPCs before it had received its initial state,
and it would reply with a RequestIgnoredResponse. The originator would see this response
and retry the operation, without any change.
After ISPN-1194, we no longer use RequestIgnoredResponse - instead a node can reply with
a StateTransferInProgressException to signal that the command targets may have changed or
(only for CommitCommands) with CommitCommand.RESEND_PREPARE to request the prepare
information on a new owner. Either way, there is no case where the originator has to
resend the command exactly the same as the first time.
We should disable the replay support completely, as this job is better handled at a
higher level.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira