]
Galder Zamarreño commented on ISPN-1860:
----------------------------------------
There's a bug in CrashedMemberDetectorListener. When node02 is started again,
CrashedMemberDetectorListener is erroneously updating the view id to 5, before node02 has
had the chance to add itself to the topology cache. The fix is for
CrashedMemberDetectorListener to only update the view id until it's removed all nodes
that have left the view, if there's any. If nodes are being added, it should do
nothing.
HotRod client topology info can get out of sync with the server
topology info
-----------------------------------------------------------------------------
Key: ISPN-1860
URL:
https://issues.jboss.org/browse/ISPN-1860
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.1.1.FINAL
Reporter: Dan Berindei
Assignee: Manik Surtani
Fix For: 5.1.2.FINAL, 5.2.0.ALPHA1
Say we have a HotRod cluster with a JGroups view A1 [A, B]. A client makes a get request
to A, and it receives topology id 1, with nodes [A, B].
Another node C joins the HotRod cluster, and the JGroups view becomes A2 [A, B, C]. It
takes a certain time for C to finish joining the topology cache, so for a limited amount
of time the topology cache on A only contains [A, B].
If the client makes another get request during this time interval, it will receive
topology id 2, but still with nodes [A, B]. So its consistent hash will not contain C.
Future requests from the same client will send topology id 2 to the server, so the server
will believe that the client's CH is [A, B, C] and won't send another topology
update until another JGroups view is installed (because of a join, leave, or merge).
Note that this can happen even if the client had C in its initial host list, because
topology updates override the initial host list.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: