[JBoss JIRA] (ISPN-8092) Scattered cache state transfer misses segments
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8092?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-8092:
-----------------------------------
The topology 8 is wrong; the segment 1 should be lost (without an owner). It seems to be a bug in {{BaseControlledConsistentHashFactory.updateMembers}} - if owners are empty, the CHF should not immediately select new owners for those segments but keep that empty instead.
I'll reduce bug severity to minor since this is a testsuite-only problem.
> Scattered cache state transfer misses segments
> ----------------------------------------------
>
> Key: ISPN-8092
> URL: https://issues.jboss.org/browse/ISPN-8092
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Final
> Reporter: Dan Berindei
> Assignee: Radim Vansa
> Priority: Critical
>
> I noticed this in the pull request for [ISPN-7997|https://github.com/infinispan/infinispan/pull/5253], which uses a {{ControlledConsistentHashFactory}} to make the stream tests more predictable.
> For simplicity, I used 3 segments, and the ownership is as follows:
> * With a full cluster ABC, A owns segment 0, B owns segment 1, and C owns segment 2
> * With a smaller cluster A, AB, or AC, A owns all the segments.
> {{ScatteredStreamIteratorTest.verifyNodeLeavesAfterSendingBackSomeData[SCATTERED_SYNC, tx=false]}} kills node B, and A immediately becomes the owner of segment 1. Then the rebalance starts and A pushes segment 2 to node C, but it doesn't try to fetch any entries from segment 1 that were backed up on node C.
> {noformat}
> 17:35:09,897 DEBUG (remote-thread-test-NodeA-p2-t5:[testCache]) [ClusterTopologyManagerImpl] Updating cluster-wide current topology for cache testCache, topology = CacheTopology{id=7, rebalanceId=4, currentCH=ScatteredConsistentHash{ns=3, rebalanced=true, owners = (3)[test-NodeA-59810: 1, test-NodeB-37315: 1, test-NodeC-50539: 1]}, pendingCH=null, unionCH=null, phase=NO_REBALANCE, actualMembers=[test-NodeA-59810, test-NodeB-37315, test-NodeC-50539], persistentUUIDs=[6118c3ba-840e-4838-a0cf-1165d3d5ec4b, 38cc2bd9-0a21-4020-97ab-909a32506fa1, 6a4f1a13-0fbb-4f92-867e-64068d574d4d]}, availability mode = AVAILABLE
> 17:35:10,974 DEBUG (remote-thread-test-NodeA-p2-t5:[testCache]) [ClusterTopologyManagerImpl] Updating cluster-wide current topology for cache testCache, topology = CacheTopology{id=8, rebalanceId=4, currentCH=ScatteredConsistentHash{ns=3, rebalanced=false, owners = (2)[test-NodeA-59810: 2, test-NodeC-50539: 1]}, pendingCH=null, unionCH=null, phase=NO_REBALANCE, actualMembers=[test-NodeA-59810, test-NodeC-50539], persistentUUIDs=[6118c3ba-840e-4838-a0cf-1165d3d5ec4b, 6a4f1a13-0fbb-4f92-867e-64068d574d4d]}, availability mode = AVAILABLE
> 17:35:10,975 TRACE (transport-thread-test-NodeA-p4-t2:[Topology-testCache]) [StateConsumerImpl] On cache testCache we have: new segments: [0, 1]; old segments: [0]
> 17:35:10,975 TRACE (transport-thread-test-NodeA-p4-t2:[Topology-testCache]) [StateConsumerImpl] On cache testCache we have: added segments: {1}; removed segments: {}
> 17:35:10,975 TRACE (transport-thread-test-NodeA-p4-t2:[Topology-testCache]) [StateConsumerImpl] This is not a rebalance, not doing anything...
> 17:35:10,976 INFO (remote-thread-test-NodeA-p2-t5:[testCache]) [CLUSTER] ISPN000310: Starting cluster-wide rebalance for cache testCache, topology CacheTopology{id=9, rebalanceId=5, currentCH=ScatteredConsistentHash{ns=3, rebalanced=false, owners = (2)[test-NodeA-59810: 2, test-NodeC-50539: 1]}, pendingCH=ScatteredConsistentHash{ns=3, rebalanced=true, owners = (2)[test-NodeA-59810: 3, test-NodeC-50539: 0]}, unionCH=null, phase=TRANSITORY, actualMembers=[test-NodeA-59810, test-NodeC-50539], persistentUUIDs=[6118c3ba-840e-4838-a0cf-1165d3d5ec4b, 6a4f1a13-0fbb-4f92-867e-64068d574d4d]}
> 17:35:10,977 TRACE (transport-thread-test-NodeA-p4-t3:[Topology-testCache]) [CacheTopology] Current consistent hash's routing table: 0: 0, 1: 0, 2: 1
> 17:35:10,977 TRACE (transport-thread-test-NodeA-p4-t3:[Topology-testCache]) [CacheTopology] Pending consistent hash's routing table: 0: 0, 1: 0, 2: 0
> 17:35:10,978 TRACE (transport-thread-test-NodeA-p4-t3:[Topology-testCache]) [ScatteredVersionManager] Node will transfer value for topology 9
> 17:35:10,978 TRACE (transport-thread-test-NodeA-p4-t3:[Topology-testCache]) [StateConsumerImpl] On cache testCache we have: new segments: [0, 1, 2]; old segments: [0, 1]
> 17:35:10,978 TRACE (transport-thread-test-NodeA-p4-t3:[Topology-testCache]) [StateConsumerImpl] On cache testCache we have: added segments: {2}; removed segments: {}
> 17:35:10,979 TRACE (transport-thread-test-NodeA-p4-t3:[Topology-testCache]) [JGroupsTransport] test-NodeA-59810 sending request 9 to all: StateRequestCommand{cache=testCache, origin=test-NodeA-59810, type=CONFIRM_REVOKED_SEGMENTS, topologyId=9, segments=null}
> 17:35:10,989 TRACE (transport-thread-test-NodeA-p4-t3:[Topology-testCache]) [StateProviderImpl] Segments to replicate and invalidate: [0, 1]
> 17:35:10,989 TRACE (transport-thread-test-NodeA-p4-t1:[]) [OutboundTransferTask] Sending last chunk to node test-NodeC-50539 containing 0 cache entries from segments [0, 1]
> 17:35:10,989 TRACE (stateTransferExecutor-thread-test-NodeA-p7-t1:[StateRequest-testCache]) [RpcManagerImpl] test-NodeA-59810 invoking StateRequestCommand{cache=testCache, origin=test-NodeA-59810, type=START_KEYS_TRANSFER, topologyId=9, segments={2}} to recipient list [test-NodeC-50539] with options RpcOptions{timeout=240000, unit=MILLISECONDS, deliverOrder=NONE, responseFilter=null, responseMode=SYNCHRONOUS_IGNORE_LEAVERS}
> 17:35:11,017 INFO (transport-thread-test-NodeA-p4-t4:[testCache]) [CLUSTER] ISPN000336: Finished cluster-wide rebalance for cache testCache, topology id = 9
> 17:35:11,017 DEBUG (transport-thread-test-NodeA-p4-t4:[testCache]) [ClusterTopologyManagerImpl] Updating cluster-wide current topology for cache testCache, topology = CacheTopology{id=10, rebalanceId=5, currentCH=ScatteredConsistentHash{ns=3, rebalanced=true, owners = (2)[test-NodeA-59810: 3, test-NodeC-50539: 0]}, pendingCH=null, unionCH=null, phase=NO_REBALANCE, actualMembers=[test-NodeA-59810, test-NodeC-50539], persistentUUIDs=[6118c3ba-840e-4838-a0cf-1165d3d5ec4b, 6a4f1a13-0fbb-4f92-867e-64068d574d4d]}, availability mode = AVAILABLE
> {noformat}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (ISPN-8092) Scattered cache state transfer misses segments
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8092?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-8092:
------------------------------
Priority: Minor (was: Critical)
> Scattered cache state transfer misses segments
> ----------------------------------------------
>
> Key: ISPN-8092
> URL: https://issues.jboss.org/browse/ISPN-8092
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Final
> Reporter: Dan Berindei
> Assignee: Radim Vansa
> Priority: Minor
>
> I noticed this in the pull request for [ISPN-7997|https://github.com/infinispan/infinispan/pull/5253], which uses a {{ControlledConsistentHashFactory}} to make the stream tests more predictable.
> For simplicity, I used 3 segments, and the ownership is as follows:
> * With a full cluster ABC, A owns segment 0, B owns segment 1, and C owns segment 2
> * With a smaller cluster A, AB, or AC, A owns all the segments.
> {{ScatteredStreamIteratorTest.verifyNodeLeavesAfterSendingBackSomeData[SCATTERED_SYNC, tx=false]}} kills node B, and A immediately becomes the owner of segment 1. Then the rebalance starts and A pushes segment 2 to node C, but it doesn't try to fetch any entries from segment 1 that were backed up on node C.
> {noformat}
> 17:35:09,897 DEBUG (remote-thread-test-NodeA-p2-t5:[testCache]) [ClusterTopologyManagerImpl] Updating cluster-wide current topology for cache testCache, topology = CacheTopology{id=7, rebalanceId=4, currentCH=ScatteredConsistentHash{ns=3, rebalanced=true, owners = (3)[test-NodeA-59810: 1, test-NodeB-37315: 1, test-NodeC-50539: 1]}, pendingCH=null, unionCH=null, phase=NO_REBALANCE, actualMembers=[test-NodeA-59810, test-NodeB-37315, test-NodeC-50539], persistentUUIDs=[6118c3ba-840e-4838-a0cf-1165d3d5ec4b, 38cc2bd9-0a21-4020-97ab-909a32506fa1, 6a4f1a13-0fbb-4f92-867e-64068d574d4d]}, availability mode = AVAILABLE
> 17:35:10,974 DEBUG (remote-thread-test-NodeA-p2-t5:[testCache]) [ClusterTopologyManagerImpl] Updating cluster-wide current topology for cache testCache, topology = CacheTopology{id=8, rebalanceId=4, currentCH=ScatteredConsistentHash{ns=3, rebalanced=false, owners = (2)[test-NodeA-59810: 2, test-NodeC-50539: 1]}, pendingCH=null, unionCH=null, phase=NO_REBALANCE, actualMembers=[test-NodeA-59810, test-NodeC-50539], persistentUUIDs=[6118c3ba-840e-4838-a0cf-1165d3d5ec4b, 6a4f1a13-0fbb-4f92-867e-64068d574d4d]}, availability mode = AVAILABLE
> 17:35:10,975 TRACE (transport-thread-test-NodeA-p4-t2:[Topology-testCache]) [StateConsumerImpl] On cache testCache we have: new segments: [0, 1]; old segments: [0]
> 17:35:10,975 TRACE (transport-thread-test-NodeA-p4-t2:[Topology-testCache]) [StateConsumerImpl] On cache testCache we have: added segments: {1}; removed segments: {}
> 17:35:10,975 TRACE (transport-thread-test-NodeA-p4-t2:[Topology-testCache]) [StateConsumerImpl] This is not a rebalance, not doing anything...
> 17:35:10,976 INFO (remote-thread-test-NodeA-p2-t5:[testCache]) [CLUSTER] ISPN000310: Starting cluster-wide rebalance for cache testCache, topology CacheTopology{id=9, rebalanceId=5, currentCH=ScatteredConsistentHash{ns=3, rebalanced=false, owners = (2)[test-NodeA-59810: 2, test-NodeC-50539: 1]}, pendingCH=ScatteredConsistentHash{ns=3, rebalanced=true, owners = (2)[test-NodeA-59810: 3, test-NodeC-50539: 0]}, unionCH=null, phase=TRANSITORY, actualMembers=[test-NodeA-59810, test-NodeC-50539], persistentUUIDs=[6118c3ba-840e-4838-a0cf-1165d3d5ec4b, 6a4f1a13-0fbb-4f92-867e-64068d574d4d]}
> 17:35:10,977 TRACE (transport-thread-test-NodeA-p4-t3:[Topology-testCache]) [CacheTopology] Current consistent hash's routing table: 0: 0, 1: 0, 2: 1
> 17:35:10,977 TRACE (transport-thread-test-NodeA-p4-t3:[Topology-testCache]) [CacheTopology] Pending consistent hash's routing table: 0: 0, 1: 0, 2: 0
> 17:35:10,978 TRACE (transport-thread-test-NodeA-p4-t3:[Topology-testCache]) [ScatteredVersionManager] Node will transfer value for topology 9
> 17:35:10,978 TRACE (transport-thread-test-NodeA-p4-t3:[Topology-testCache]) [StateConsumerImpl] On cache testCache we have: new segments: [0, 1, 2]; old segments: [0, 1]
> 17:35:10,978 TRACE (transport-thread-test-NodeA-p4-t3:[Topology-testCache]) [StateConsumerImpl] On cache testCache we have: added segments: {2}; removed segments: {}
> 17:35:10,979 TRACE (transport-thread-test-NodeA-p4-t3:[Topology-testCache]) [JGroupsTransport] test-NodeA-59810 sending request 9 to all: StateRequestCommand{cache=testCache, origin=test-NodeA-59810, type=CONFIRM_REVOKED_SEGMENTS, topologyId=9, segments=null}
> 17:35:10,989 TRACE (transport-thread-test-NodeA-p4-t3:[Topology-testCache]) [StateProviderImpl] Segments to replicate and invalidate: [0, 1]
> 17:35:10,989 TRACE (transport-thread-test-NodeA-p4-t1:[]) [OutboundTransferTask] Sending last chunk to node test-NodeC-50539 containing 0 cache entries from segments [0, 1]
> 17:35:10,989 TRACE (stateTransferExecutor-thread-test-NodeA-p7-t1:[StateRequest-testCache]) [RpcManagerImpl] test-NodeA-59810 invoking StateRequestCommand{cache=testCache, origin=test-NodeA-59810, type=START_KEYS_TRANSFER, topologyId=9, segments={2}} to recipient list [test-NodeC-50539] with options RpcOptions{timeout=240000, unit=MILLISECONDS, deliverOrder=NONE, responseFilter=null, responseMode=SYNCHRONOUS_IGNORE_LEAVERS}
> 17:35:11,017 INFO (transport-thread-test-NodeA-p4-t4:[testCache]) [CLUSTER] ISPN000336: Finished cluster-wide rebalance for cache testCache, topology id = 9
> 17:35:11,017 DEBUG (transport-thread-test-NodeA-p4-t4:[testCache]) [ClusterTopologyManagerImpl] Updating cluster-wide current topology for cache testCache, topology = CacheTopology{id=10, rebalanceId=5, currentCH=ScatteredConsistentHash{ns=3, rebalanced=true, owners = (2)[test-NodeA-59810: 3, test-NodeC-50539: 0]}, pendingCH=null, unionCH=null, phase=NO_REBALANCE, actualMembers=[test-NodeA-59810, test-NodeC-50539], persistentUUIDs=[6118c3ba-840e-4838-a0cf-1165d3d5ec4b, 6a4f1a13-0fbb-4f92-867e-64068d574d4d]}, availability mode = AVAILABLE
> {noformat}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (ISPN-8095) Eviction support for counters
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-8095:
---------------------------------
Summary: Eviction support for counters
Key: ISPN-8095
URL: https://issues.jboss.org/browse/ISPN-8095
Project: Infinispan
Issue Type: Feature Request
Components: Clustered Counter
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
[Needs Discussion]
Eviction might be useful if the user needs to limit amount of counters that can be created. While it would be possible to strong counter, the weak counters can be a problem.
Other issue is the volatile counters, which value will be lost if evicted.
Manual eviction might be considered as well...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (ISPN-8094) Support expiration per counter
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-8094:
---------------------------------
Summary: Support expiration per counter
Key: ISPN-8094
URL: https://issues.jboss.org/browse/ISPN-8094
Project: Infinispan
Issue Type: Feature Request
Components: Clustered Counter
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
This would allow a counter to expire (lifespan/max-idle). If expired, an update will recreate the counter with its initial value and apply the update. A read operation in a expired counter returns its initial value (without recreate).
Configuration change:
{code:xml}
<strong-counter ...>
<expiration lifespan="xxxx" max-idle="yyy/> //similar to cache expiration
</strong-counter>
{code}
or add it to the tag attributes
{code:xml}
<strong-counter lifespan="xxxx" max-idle="yyyy"/>
{code}
IMO, the first option is better...
Note: probably expiration won't work with weak counters. Since its value is sliced in multiple keys, if one key expire will make the counter's value inconsistent...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (ISPN-8093) Remove operation for counters
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-8093:
---------------------------------
Summary: Remove operation for counters
Key: ISPN-8093
URL: https://issues.jboss.org/browse/ISPN-8093
Project: Infinispan
Issue Type: Feature Request
Components: Clustered Counter
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Allow counters to be removed. If an operation finds out that the counter doesn't exists, it is recreated with its initial value and the operation is replied.
If a getValue is invoked and the counter doesn't exist, it returns its initial value without recreating the counter.
New methods to the API:
{code:java}
CounterManager.removeCounter(String counterName) //remove the counter with this name
StrongCounter.remove() //removes the counter represent by this instance
WeakCounter.remove() //same as above
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months