[infinispan-issues] [JBoss JIRA] (ISPN-1860) HotRod client topology info can get out of sync with the server topology info

Galder Zamarreño (JIRA) jira-events at lists.jboss.org
Thu Feb 16 05:45:36 EST 2012


    [ https://issues.jboss.org/browse/ISPN-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667051#comment-12667051 ] 

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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



More information about the infinispan-issues mailing list