[JBoss JIRA] (ISPN-8097) ScatteredCrashInSequenceTest.testSplit failures
by Radim Vansa (JIRA)
Radim Vansa created ISPN-8097:
---------------------------------
Summary: ScatteredCrashInSequenceTest.testSplit failures
Key: ISPN-8097
URL: https://issues.jboss.org/browse/ISPN-8097
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.1.0.Final
Reporter: Radim Vansa
Assignee: Radim Vansa
In PrefetchInterceptor, when looking up who could be the new owner of the segment (during key/value transfer) the forked command did not have topologyId set. Therefore the cache topology (9) vs. command topology check was not executed, and the command has thrown AOLE.
STI caught this AOLE but already with the original command (topology 10), so it has decided that topology 11 is needed and waiting for this has timed out.
In the solution in PR we set the topology id which in turn results in throwing OTE with requested topology 10 directly.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (ISPN-8097) ScatteredCrashInSequenceTest.testSplit failures
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8097?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-8097:
------------------------------
Status: Open (was: New)
> ScatteredCrashInSequenceTest.testSplit failures
> ------------------------------------------------
>
> Key: ISPN-8097
> URL: https://issues.jboss.org/browse/ISPN-8097
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
>
> In PrefetchInterceptor, when looking up who could be the new owner of the segment (during key/value transfer) the forked command did not have topologyId set. Therefore the cache topology (9) vs. command topology check was not executed, and the command has thrown AOLE.
> STI caught this AOLE but already with the original command (topology 10), so it has decided that topology 11 is needed and waiting for this has timed out.
> In the solution in PR we set the topology id which in turn results in throwing OTE with requested topology 10 directly.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 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 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)
8 years, 8 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)
8 years, 8 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)
8 years, 8 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)
8 years, 8 months