[infinispan-issues] [JBoss JIRA] (ISPN-3223) HotRod 2.0 Client recieves stale toplogy view on instance leave

[Alan Field (JIRA)]

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

Alan Field commented on ISPN-3223:
----------------------------------

Hey Galder,

This is what I see with a 7.2.0-SNAPSHOT build of today's code (Feb 27 2015):

(Start one server, then start the client)
15:59:33,778 INFO  [org.infinispan.client.hotrod.impl.protocol.Codec20] (main) ISPN004006: localhost/127.0.0.1:11222 sent new topology view (id=0) containing 1 addresses: [/127.0.0.1:11222]
15:59:33,801 INFO  [org.infinispan.client.hotrod.RemoteCacheManager] (main) ISPN004021: Infinispan version: 7.2.0-SNAPSHOT
15:59:33,809 INFO  [org.infinispan.client.hotrod.impl.protocol.Codec20] (main) ISPN004006: localhost/127.0.0.1:11222 sent new topology view (id=0) containing 1 addresses: [/127.0.0.1:11222]
15:59:33,810 INFO  [org.infinispan.test.CSPut] (main) Got cache: org.infinispan.client.hotrod.impl.RemoteCacheImpl at 735b478
15:59:34,338 INFO  [org.infinispan.test.CSPut] (main) Loop 1000 finished.
15:59:34,593 INFO  [org.infinispan.test.CSPut] (main) Loop 2000 finished.
15:59:34,793 INFO  [org.infinispan.test.CSPut] (main) Loop 3000 finished.
(Start second server)
15:59:47,319 INFO  [org.infinispan.client.hotrod.impl.protocol.Codec20] (main) ISPN004006: localhost/127.0.0.1:11222 sent new topology view (id=1) containing 1 addresses: [/127.0.0.1:11222]
15:59:48,903 INFO  [org.infinispan.test.CSPut] (main) Loop 134000 finished.
15:59:49,008 INFO  [org.infinispan.client.hotrod.impl.protocol.Codec20] (main) ISPN004006: localhost/127.0.0.1:11222 sent new topology view (id=2) containing 2 addresses: [/127.0.0.1:11232, /127.0.0.1:11222]
15:59:49,008 INFO  [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory] (main) ISPN004014: New server added(/127.0.0.1:11232), adding to the pool.
15:59:50,130 INFO  [org.infinispan.test.CSPut] (main) Loop 135000 finished.
15:59:50,779 INFO  [org.infinispan.test.CSPut] (main) Loop 136000 finished.
15:59:51,584 INFO  [org.infinispan.test.CSPut] (main) Loop 137000 finished.
(Stop a server)
15:59:59,513 INFO  [org.infinispan.client.hotrod.impl.protocol.Codec20] (main) ISPN004006: /127.0.0.1:11232 sent new topology view (id=3) containing 1 addresses: [/127.0.0.1:11232]
15:59:59,514 INFO  [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory] (main) ISPN004016: Server not in cluster anymore(/127.0.0.1:11222), removing from the pool.
15:59:59,723 INFO  [org.infinispan.client.hotrod.impl.protocol.Codec20] (main) ISPN004006: /127.0.0.1:11232 sent new topology view (id=4) containing 1 addresses: [/127.0.0.1:11232]
15:59:59,834 INFO  [org.infinispan.test.CSPut] (main) Loop 158000 finished.
15:59:59,916 INFO  [org.infinispan.test.CSPut] (main) Loop 159000 finished.
15:59:59,986 INFO  [org.infinispan.test.CSPut] (main) Loop 160000 finished.

It looks like the issue is not longer there.

Thanks,
Alan

> HotRod 2.0 Client recieves stale toplogy view on instance leave
> ---------------------------------------------------------------
>
>                 Key: ISPN-3223
>                 URL: https://issues.jboss.org/browse/ISPN-3223
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Remote Protocols
>    Affects Versions: 5.2.4.Final, 5.3.0.CR1, 7.0.0.Beta1
>            Reporter: Takayoshi Kimura
>            Assignee: Galder Zamarreño
>         Attachments: hr-protocol-13.log, hr-protocol-20.log
>
>
> When killed a HotRod server node, HotRod Clinet sometimes recieves a stale toplogy view which includes the dead node and uses it as a latest view. In this case the client keeps trying to connect that node and keeps failing.
> Looks like the AbstractEncoder1x.generateTopologyResponse() takes care of node join but doesn't handle node leave:
> {noformat}
> if (!serverEndpointsMap.keySet.containsAll(cacheMembers)) {
> {noformat}
> For example, serverEndpointsMap.keySet is [A, B, C] and the actual cacheMembers is [A, B].



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)