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

[Dan Berindei (JIRA)]

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

Dan Berindei commented on ISPN-1860:
------------------------------------

Galder, you're absolutely right, I forgot about ISPN-1826 so my description is probably not accurate.

The actual scenario was a little more complicated, see this picture: http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-QE/job/edg-60-experiments-mlinhard/199/artifact/report/stats-throughput.png
A node (node02 in the picture) was killed 5 minutes into the test, then it was started back up after another 5 minutes. However, it didn't start handling client requests for yet another 5 minutes, until another node (node04) was killed.

Here are the TRACE logs: http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-QE/job/edg-60-experiments-mlinhard/199/artifact/report/serverlogs.zip
                
> 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.2.0.FINAL
>
>
> 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