[infinispan-issues] [JBoss JIRA] (ISPN-7884) StackOverflowException caused by GetAllCommand
[
https://issues.jboss.org/browse/ISPN-7884?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-7884:
------------------------------------
[~rvansa] I'm not sure if it's related, but I've noticed that after a leave,
the coordinator sometimes broadcasts a new topology with the same CH and only the actual
members changed, and I don't think that's necessary and/or correct. If the cache
is not entering degraded mode we're going to broadcast another topology with the
leaver removed from the current CH immediately anyway, so all the intermediate topology
doesn't buy us anything. On the contrary, any commands that got a `SuspectedException`
and were waiting for a new topology to retry will retry too soon, and will get a
`SuspectedException` again.
StackOverflowException caused by GetAllCommand
----------------------------------------------
Key: ISPN-7884
URL: https://issues.jboss.org/browse/ISPN-7884
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.1.0.Alpha1
Reporter: Radim Vansa
Assignee: Radim Vansa
GetAllCommand in BaseDistributionInterceptor handles all unsuccessful responses by
throwing OutdatedTopologyException.
BaseStateTransferInterceptor assumes that this is due to UnsureResponse in a scenario
where it should be possible to retry the command immediately.
If this occurs due to CacheNotFoundResponse (node being suspected) but before the
availability mode is updated/consistent hash is updated with lost segments assigned to
other nodes, the command is retried in a loop up to a point where the thread hits stack
overflow.
This does not affect regular cache.get() since this one throws AllOwnersLostException
instead and this is treated differently in BaseStateTransferInterceptor.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)