[
https://issues.jboss.org/browse/ISPN-6740?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-6740:
-----------------------------------
Description:
Infinispan Caches now support storing persistent views. When these are loaded, these might
be loaded with topology ID 0:
{code}
2016-05-31 10:20:04,254 INFO [org.infinispan.globalstate.impl.GlobalStateManagerImpl]
(MSC service thread 1-3)
ISPN000389: Loaded global state, version=9.0.0-SNAPSHOT
timestamp=2016-05-30T12:03:33.822Z
....
2016-05-31 10:20:07,867 TRACE [org.infinispan.statetransfer.StateTransferManagerImpl] (MSC
service thread 1-6)
Installing new cache topology CacheTopology{id=0, rebalanceId=0,
currentCH=DefaultConsistentHash{ns=20, owners = (3)[node5: 7+5, node4: 7+7, node6: 6+8]},
pendingCH=null, unionCH=null, actualMembers=[node5, node4, node6], persistentUUIDs=[
bb76729d-2b30-4e54-8108-4ac1db9a04cf, bb76729d-2b30-4e54-8108-4ac1db9a04cf,
bb76729d-2b30-4e54-8108-4ac1db9a04cf]} on cache default
{code}
If there's no further view changes, the topology ID will remain 0. When a Hot Rod
client first connects, it sends its view topology as 0 so that it receives a newly
installed topology, but if the topology is already 0 in the server, the server won't
send the installed topology, even though it should be newer than having no topology.
We should start numbering topologies in server starting from 1 instead. That avoids this
issue. This is easier than forcing clients to send -1 as initial topology because the
topology ID is currently defined as VInt that can only 0 or positive number.
Also, some extra log messages indicating that the cache topology installed comes from
persisted state would be handy for debugging.
was:
Infinispan Caches now support storing persistent views. When these are loaded, these might
be loaded with topology ID 0:
{code}
2016-05-31 10:20:04,254 INFO [org.infinispan.globalstate.impl.GlobalStateManagerImpl]
(MSC service thread 1-3) ISPN000389: Loaded global state, version=9.0.0-SNAPSHOT
timestamp=2016-05-30T12:03:33.822Z
....
2016-05-31 10:20:07,867 TRACE [org.infinispan.statetransfer.StateTransferManagerImpl] (MSC
service thread 1-6) Installing new cache topology CacheTopology{id=0, rebalanceId=0,
currentCH=DefaultConsistentHash{ns=20, owners = (3)[node5: 7+5, node4: 7+7, node6: 6+8]},
pendingCH=null, unionCH=null, actualMembers=[node5, node4, node6],
persistentUUIDs=[bb76729d-2b30-4e54-8108-4ac1db9a04cf,
bb76729d-2b30-4e54-8108-4ac1db9a04cf, bb76729d-2b30-4e54-8108-4ac1db9a04cf]} on cache
default
{code}
If there's no further view changes, the topology ID will remain 0. When a Hot Rod
client first connects, it sends its view topology as 0 so that it receives a newly
installed topology, but if the topology is already 0 in the server, the server won't
send the installed topology, even though it should be newer than having no topology.
We should start numbering topologies in server starting from 1 instead. That avoids this
issue. This is easier than forcing clients to send -1 as initial topology because the
topology ID is currently defined as VInt that can only 0 or positive number.
Also, some extra log messages indicating that the cache topology installed comes from
persisted state would be handy for debugging.
Client topologies not updated when cache topology loaded from
persistent state
------------------------------------------------------------------------------
Key: ISPN-6740
URL:
https://issues.jboss.org/browse/ISPN-6740
Project: Infinispan
Issue Type: Bug
Components: Remote Protocols, State Transfer
Affects Versions: 9.0.0.Alpha2, 8.2.2.Final
Reporter: Galder Zamarreño
Assignee: Dan Berindei
Fix For: 9.0.0.Alpha3, 9.0.0.Final
Infinispan Caches now support storing persistent views. When these are loaded, these
might be loaded with topology ID 0:
{code}
2016-05-31 10:20:04,254 INFO [org.infinispan.globalstate.impl.GlobalStateManagerImpl]
(MSC service thread 1-3)
ISPN000389: Loaded global state, version=9.0.0-SNAPSHOT
timestamp=2016-05-30T12:03:33.822Z
....
2016-05-31 10:20:07,867 TRACE [org.infinispan.statetransfer.StateTransferManagerImpl]
(MSC service thread 1-6)
Installing new cache topology CacheTopology{id=0, rebalanceId=0,
currentCH=DefaultConsistentHash{ns=20, owners = (3)[node5: 7+5, node4: 7+7, node6: 6+8]},
pendingCH=null, unionCH=null, actualMembers=[node5, node4, node6], persistentUUIDs=[
bb76729d-2b30-4e54-8108-4ac1db9a04cf, bb76729d-2b30-4e54-8108-4ac1db9a04cf,
bb76729d-2b30-4e54-8108-4ac1db9a04cf]} on cache default
{code}
If there's no further view changes, the topology ID will remain 0. When a Hot Rod
client first connects, it sends its view topology as 0 so that it receives a newly
installed topology, but if the topology is already 0 in the server, the server won't
send the installed topology, even though it should be newer than having no topology.
We should start numbering topologies in server starting from 1 instead. That avoids this
issue. This is easier than forcing clients to send -1 as initial topology because the
topology ID is currently defined as VInt that can only 0 or positive number.
Also, some extra log messages indicating that the cache topology installed comes from
persisted state would be handy for debugging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)