[infinispan-issues] [JBoss JIRA] (ISPN-8182) Asynchronous commands should be retried if topology is outdated
[
https://issues.jboss.org/browse/ISPN-8182?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-8182:
------------------------------------
-1 to retry from the originator, because the whole point of asynchronous replication is to
not keep track of commands after they were sent to the owners. In other words, the fact
that updates can be lost is the main reason why {{cache.put(k, v)}}/*DIST_ASYNC* is faster
than {{cache.putAsync(k, v)}}/*DIST_SYNC*.
OTOH it's not ok that the remote node throws an {{OutdatedTopologyException}} and then
pretends it can send it back to the originator (at least in the log), and the originator
could retry the command. The remote node should either not throw the
{{OutdatedTopologyException}} at all, or it should catch it and retry locally.
Asynchronous commands should be retried if topology is outdated
---------------------------------------------------------------
Key: ISPN-8182
URL: https://issues.jboss.org/browse/ISPN-8182
Project: Infinispan
Issue Type: Enhancement
Components: Core
Affects Versions: 9.1.0.Final
Reporter: Galder Zamarreño
If an asynchronous command fails at a remote node, it should be retried.
I'm not sure how feasible this really is. One possible solution could be this: having
NACK style implementation where by default the originator assumes an asynchronous command
has been executed, but if the receiver tells it that the topology is outdated, the
originator retries?
This is related to ISPN-8027 where we've discovered that some updates are not applied
when asynchronous commands to update the Hibernate 2L timestamp cache fail as a result of
an outdated topology.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)