[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=12756863#comment-12756863 ] 

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

With the ISPN-2632 fix we send the cache topology id to the client instead of the JGroups view id, so accessing a replicated (or even local-mode) cache won't break future updates.

But the problem remains that the client only keeps one CH for each HotRod cache manager, and the server has a different CH for each cache. So if a node joins and a client's first request is for a replicated cache, the topology id on the client is incremented (by 2) and the next request for a distributed cache won't receive any topology update. The proper solution here is to keep one CH per cache on the client, as well.

Note that sending a CH for replicated caches isn't necessarily a good idea - all requests would go to the coordinator, because that's the primary owner of all the keys in replicated mode.


                
> 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: Remote protocols
>    Affects Versions: 5.1.1.FINAL
>            Reporter: Dan Berindei
>            Assignee: Galder Zamarreño
>             Fix For: 5.3.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