[infinispan-issues] [JBoss JIRA] (ISPN-1855) Accessing a non-distributed cache from a RemoteCacheManager can break topology updates

[Dan Berindei (JIRA)]

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

Dan Berindei commented on ISPN-1855:
------------------------------------

There's another intermittent failure in HotRodDistributionTest.test that I missed in my commit for ISPN-2249, and I think it's linked to this JIRA (or at least its solution is). 

When a node leaves, we first remove the node from the CH (without incrementing the topology id), then we rebalance the CH. The rebalance also has two phases, in the first phase we just add new owners for each segment to get to numOwners, and in the second phase we reorder those to even out the number of segments for which each node is the primary owner. Each of these phases increments the topology id.

So if a client's topology id would map to the cache's topology id, it would receive a new topology after each of these phases. But because the client's topology id maps to the cluster's JGroups view id, it will only receive one topology update - and that update is not guaranteed to be the CH after the rebalance has ended.
                
> Accessing a non-distributed cache from a RemoteCacheManager can break topology updates
> --------------------------------------------------------------------------------------
>
>                 Key: ISPN-1855
>                 URL: https://issues.jboss.org/browse/ISPN-1855
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Cache Server
>    Affects Versions: 5.1.1.FINAL
>            Reporter: Dan Berindei
>            Assignee: Galder Zamarreño
>             Fix For: 5.2.0.Final
>
>
> RemoteCacheManager uses a single consistent hash to map requests to different servers, but caches on the server may have different CHs (or even no CH if the cache is not in distributed mode).
> If the first request goes to a on-distributed cache, the client will never request an updated CH and so it will use a round robin strategy for routing request to all the caches. Obviously this is not optimal for distributed caches.
> Each distributed cache can also have different members since 5.1, so it would be best if we kept a separate CH per cache on the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira