[
https://issues.jboss.org/browse/ISPN-2402?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-2402:
------------------------------------
Just ignoring the suspected recipients is not enough.
In the "non-transactional concurrent" case, the originator only contacts the
primary owner, so if the primary owner leaves it needs to retry the RPC on the new primary
owner.
In transactional mode, the prepare command only acquires locks on the primary owner, so if
the primary owner is suspected we don't have any locks and we must retry the prepare
on the new primary owner.
Cache operations or transactions should never fail with
SuspectException
------------------------------------------------------------------------
Key: ISPN-2402
URL:
https://issues.jboss.org/browse/ISPN-2402
Project: Infinispan
Issue Type: Task
Components: RPC, State transfer
Affects Versions: 5.2.0.Beta2
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Minor
Labels: 5.2.x
Fix For: 5.3.0.Beta1
Attachments: vrstt.log
This is an extension of ISPN-1896 of sorts, but for all the cache operations that are
visible to the user.
After a node leaves, the other nodes that have sent commands to that node should either
ignore SuspectExceptions or, if not possible, they should retry the operation (e.g. if
they didn't get any response back).
For example, VersionReplStateTransferTest quite often on my machine with a
SuspectException, because the versioned prepare command expects a response from the
coordinator and the coordinator has just left.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira