[JBoss JIRA] (ISPN-1855) Accessing a non-distributed cache from a RemoteCacheManager can break topology updates
1:01 p.m.
Dan Berindei created ISPN-1855:
----------------------------------
Summary: 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
Affects Versions: 5.1.1.FINAL
Reporter: Dan Berindei
Assignee: Manik Surtani
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:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:26 a.m.
[
https://issues.jboss.org/browse/ISPN-1855?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-1855:
-----------------------------------
Assignee: Galder Zamarreño (was: Manik Surtani)
Component/s: Cache Server
Forum Reference: https://community.jboss.org/message/715455 (was:
https://community.jboss.org/message/715455)
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
6:51 p.m.
[
https://issues.jboss.org/browse/ISPN-1855?page=com.atlassian.jira.plugin....
]
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
6:06 p.m.
[
https://issues.jboss.org/browse/ISPN-1855?page=com.atlassian.jira.plugin....
]
Mircea Markus updated ISPN-1855:
--------------------------------
Fix Version/s: 5.2.0.CR1
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.CR1, 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
6:11 p.m.
[
https://issues.jboss.org/browse/ISPN-1855?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-1855:
-----------------------------------
Fix Version/s: 6.0.0.Final
(was: 5.2.0.Final)
(was: 5.2.0.CR1)
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: 6.0.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
4159
days inactive
4459
days old
infinispan-issues@lists.jboss.org
4 comments
3 participants
participants (3)
-
Dan Berindei (JIRA) -
Galder Zamarreño (JIRA)
-
Mircea Markus (JIRA)