April 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8962) PreferAvailabilityStrategy: Rely less on the stable topology

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8962?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8962: ---------------------------------- Fix Version/s: 9.3.0.Beta1 (was: 9.3.0.Alpha1) > PreferAvailabilityStrategy: Rely less on the stable topology > ------------------------------------------------------------ > > Key: ISPN-8962 > URL: https://issues.jboss.org/browse/ISPN-8962 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.2.2.Final, 9.3.0.Beta1 > > > {{PreferAvailabilityStrategy}} checks the size of the stable topology, and only considers cache topologies that are derived from the biggest topology (in size) when picking a post-merge topology. > Unfortunately, in some situations this algorithm fails pretty badly. If a node has a very long GC pause, when it comes back it will report the old topology *and* the old stable topology. If the rest of the cluster rebalanced, it now has both a smaller current topology and a smaller stable topology. > Furthermore, the stable topology is updated asynchronously, independent from the current topology. So even if there's a split and the minority partition installs a current topology with fewer members, it may take some time for its stable topology to be updated with fewer members. In fact, it appears that when a rebalance is not needed (e.g. because the partition has a single node), the stable topology is never updated! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9067) Tests should set the node name even for non-clustered cache manager

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9067?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9067: ---------------------------------- Fix Version/s: 9.3.0.Beta1 (was: 9.3.0.Alpha1) > Tests should set the node name even for non-clustered cache manager > ------------------------------------------------------------------- > > Key: ISPN-9067 > URL: https://issues.jboss.org/browse/ISPN-9067 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Core > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.3.0.Beta1 > > > The node name is included in the thread name by all the internal executors, but non-clustered cache managers don't have a node name, and that makes it harder to filter log messages for a particular test. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9072) Document Protobuf annotated collection null set callbacks

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9072?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9072: ---------------------------------- Fix Version/s: 9.3.0.Beta1 (was: 9.3.0.Alpha1) > Document Protobuf annotated collection null set callbacks > --------------------------------------------------------- > > Key: ISPN-9072 > URL: https://issues.jboss.org/browse/ISPN-9072 > Project: Infinispan > Issue Type: Task > Components: Documentation-Query > Affects Versions: 9.2.1.Final > Reporter: Galder Zamarreño > Assignee: Adrian Nistor > Fix For: 9.3.0.Beta1, 9.3.0.Final > > > When using collection fields in Protobuf annotated classes, empty collections are marshalled into the same value as {{null}}, because Protobuf only has repeated fields and no fields is represented as {{null}}. > This means that if you have an entity with an empty collection, when it's deserialized the collection will be null. This can be confusing for users and should be documented. > [~anistor] had some ideas on how to improve this: > {code} > <anistor> I'm thinking of a way to make this easier for users that > would prefer an empty collection being set instead of a > null. would be possible by adding a new attribute for this in > @ProtoField anotation > > that'd be more predictable > <anistor> would still not give you at deserializtion what was written > during serialization. we do not have a null marker > <anistor> it would just give you an empty collection if you prefer > <anistor> instead of null > > that option should be enabled by default > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9060) AsynchronousInvocationTest.testNonCacheRpcCommands always takes 30 seconds

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9060?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9060: ---------------------------------- Fix Version/s: 9.3.0.Beta1 (was: 9.3.0.Alpha1) > AsynchronousInvocationTest.testNonCacheRpcCommands always takes 30 seconds > -------------------------------------------------------------------------- > > Key: ISPN-9060 > URL: https://issues.jboss.org/browse/ISPN-9060 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.3.0.Beta1 > > > The test should fail, but {{CountDownLatchResponse}} uses {{CountDownLatch.await()}} and doesn't check the result. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9054) Upgrade to Aesh 1.0

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9054?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9054: ---------------------------------- Fix Version/s: 9.3.0.Beta1 (was: 9.3.0.Alpha1) > Upgrade to Aesh 1.0 > ------------------- > > Key: ISPN-9054 > URL: https://issues.jboss.org/browse/ISPN-9054 > Project: Infinispan > Issue Type: Component Upgrade > Components: CLI > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.3.0.Beta1 > > > Aesh 1.0 has been released, and is currently used by Wildfly 12.x. 1.0 has several differences to Aesh 0.66.x, most notably the introduction of the aesh-readline project and the removal of AeshConsoleCallback. The upgrade is non-trivial, however due to some of the new features provided by Aesh 1.x, it could greatly reduce the amount of code required. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9047) Enable view bundling in JGroups configurations

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9047?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9047: ---------------------------------- Fix Version/s: 9.3.0.Beta1 (was: 9.3.0.Alpha1) > Enable view bundling in JGroups configurations > ---------------------------------------------- > > Key: ISPN-9047 > URL: https://issues.jboss.org/browse/ISPN-9047 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.3.0.Beta1 > > > We only disabled view bundling in all our JGroups configuration as a workaround for JGRP-2028, which has been fixed in JGroups 4.0. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9032) OperationsDuringMergeConflictTest.testPartitionMergePolicy random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9032?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9032: ---------------------------------- Fix Version/s: 9.3.0.Beta1 (was: 9.3.0.Alpha1) > OperationsDuringMergeConflictTest.testPartitionMergePolicy random failures > -------------------------------------------------------------------------- > > Key: ISPN-9032 > URL: https://issues.jboss.org/browse/ISPN-9032 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Assignee: Ryan Emerson > Labels: testsuite_stability > Fix For: 9.3.0.Beta1 > > > The test modifies a key in both partitions and checks that each partition still sees its own value for a while after receiving the [merged cluster view|https://github.com/infinispan/infinispan/blob/ee87349f0b134b53b3090f...]. > It installs a {{BlockStateResponseCommandHandler}} to block the conflict resolution responses and to keep the pre-merge values in the non-preferred topology owners. However, it does not block the installation of the {{CONFLICT_RESOLUTION}} cache topology. And during conflict resolution the read CH is the preferred topology's read CH, so non-preferred topology owners will ask the primary owner for the value: > {noformat} > 17:12:07,088 INFO (testng-Test:[]) [JGroupsTransport] ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[Test-NodeI-48950|10] (4) [Test-NodeI-48950, Test-NodeJ-6577, Test-NodeK-2872, Test-NodeL-23686], 2 subgroups: [Test-NodeI-48950|8] (2) [Test-NodeI-48950, Test-NodeJ-6577], [Test-NodeK-2872|9] (2) [Test-NodeK-2872, Test-NodeL-23686] > 17:12:07,134 TRACE (stateTransferExecutor-thread-Test-NodeI-p50536-t2:[Merge-10]) [DefaultConflictManager] Cache ___defaultcache attempting to receive all replicas for segment 0 with topology CacheTopology{id=20, rebalanceId=7, currentCH=DefaultConsistentHash{ns=256, owners = (2)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134]}, pendingCH=DefaultConsistentHash{ns=256, owners = (4)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134, Test-NodeI-48950: 0+256, Test-NodeJ-6577: 0+256]}, unionCH=DefaultConsistentHash{ns=256, owners = (4)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134, Test-NodeI-48950: 0+256, Test-NodeJ-6577: 0+256]}, phase=CONFLICT_RESOLUTION, actualMembers=[Test-NodeK-2872, Test-NodeL-23686, Test-NodeI-48950, Test-NodeJ-6577], persistentUUIDs=[40b58191-37f1-4fa4-8e4b-f1a7c17bfa59, 208d742d-ecc9-4792-9dd5-f74d5666f5a2, d8914096-a5a4-4e1e-95a0-27c50fee9999, 7464e58b-5e23-4c1b-909e-4e53055f12ca]} > 17:12:07,212 TRACE (testng-Test:[]) [BaseDistributionInterceptor] Perform remote get for key MagicKey{13A4/DDFB0E77/56@Test-NodeI-48950}. currentTopologyId=20, owners=[Test-NodeK-2872, Test-NodeL-23686] > 17:12:07,212 TRACE (testng-Test:[]) [RpcManagerImpl] Test-NodeI-48950 invoking ClusteredGetCommand{key=MagicKey{13A4/DDFB0E77/56@Test-NodeI-48950}, flags=[]} to recipient list [Test-NodeK-2872, Test-NodeL-23686] with options RpcOptions{timeout=15000, unit=MILLISECONDS, deliverOrder=NONE, responseFilter=org.infinispan.interceptors.impl.BaseRpcInterceptor$1@241e783a, responseMode=WAIT_FOR_VALID_RESPONSE} > 17:12:07,225 TRACE (jgroups-4,Test-NodeI-48950:[]) [CommandAwareRpcDispatcher] Got acceptable response: Responses{ > Test-NodeK-2872: value=SuccessfulResponse{responseValue=ImmortalCacheValue {value=B}} , received=true, suspected=false > 17:12:07,226 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.conflict.impl.OperationsDuringMergeConflictTest.testPartitionMergePolicy > java.lang.AssertionError: Key=MagicKey{13A4/DDFB0E77/56@Test-NodeI-48950}, Value=A, Cache Index=0, Topology=CacheTopology{id=20, rebalanceId=7, currentCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (2)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134]}, pendingCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (4)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134, Test-NodeI-48950: 0+256, Test-NodeJ-6577: 0+256]}, unionCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (4)[Test-NodeK-2872: 134+122, Test-NodeL-23686: 122+134, Test-NodeI-48950: 0+256, Test-NodeJ-6577: 0+256]}, phase=CONFLICT_RESOLUTION, actualMembers=[Test-NodeK-2872, Test-NodeL-23686, Test-NodeI-48950, Test-NodeJ-6577], persistentUUIDs=[40b58191-37f1-4fa4-8e4b-f1a7c17bfa59, 208d742d-ecc9-4792-9dd5-f74d5666f5a2, d8914096-a5a4-4e1e-95a0-27c50fee9999, 7464e58b-5e23-4c1b-909e-4e53055f12ca]} expected:<A> but was:<B> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) ~[testng-6.8.8.jar:?] > at org.infinispan.conflict.impl.BaseMergePolicyTest.assertCacheGet(BaseMergePolicyTest.java:160) ~[test-classes/:?] > at org.infinispan.conflict.impl.OperationsDuringMergeConflictTest.performMerge(OperationsDuringMergeConflictTest.java:121) ~[test-classes/:?] > at org.infinispan.conflict.impl.BaseMergePolicyTest.testPartitionMergePolicy(BaseMergePolicyTest.java:116) ~[test-classes/:?] > {noformat} > https://ci.infinispan.org/job/Infinispan/job/master/543/testReport/org.in... > Maybe we should use the union CH for reading during conflict resolution instead? > Speaking of which, {{PreferAvailabilityStrategy}} sets the {{unionCH}} field in the conflict resolution {{CacheTopology}}, but it is ignored because {{CacheTopologyControlCommand}} doesn't have a field for it. We should set {{unionCH=null}} in {{PreferAvailabilityStrategy}} to make things clearer. We should also try to reduce the number of times we log the cache topology during conflict resolution (even if it's only at trace level). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9029) Add test for exception eviction dropping entries after node leave

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9029?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9029: ---------------------------------- Fix Version/s: 9.3.0.Beta1 (was: 9.3.0.Alpha1) > Add test for exception eviction dropping entries after node leave > ----------------------------------------------------------------- > > Key: ISPN-9029 > URL: https://issues.jboss.org/browse/ISPN-9029 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Core > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Assignee: William Burns > Fix For: 9.3.0.Beta1 > > > {{ExceptionEvictionTest}} tests what happens when a node is added and N*limit existing entries are redistributed among N+1 nodes. We also need to test what happens when a node crashes and N*limit entries are redistributed among N-1 nodes. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9028) Write-only segments should be invalidated during the READ_NEW phase

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9028?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9028: ---------------------------------- Fix Version/s: 9.3.0.Beta1 (was: 9.3.0.Alpha1) > Write-only segments should be invalidated during the READ_NEW phase > ------------------------------------------------------------------- > > Key: ISPN-9028 > URL: https://issues.jboss.org/browse/ISPN-9028 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 9.3.0.Beta1 > > > When a rebalance removes a segment X from node A, node A keeps updating entries in segment X until the rebalance finishes, and only deletes the entries of segment X after entering the NO_REBALANCE phase. > This is problematic for tests that work with the data container directly, because {{waitForNoRebalance()}} doesn't wait for the removal of stale entries. The test will work without an explicit wait most of the time, so this is a recipe for random test failures (e.g. ISPN-8728). > As described in ISPN-5021, we can prevent any writes to segment X at the start of the READ_NEW_WRITE_ALL phase, send the phase confirmation to the coordinator, and then remove the entries asynchronously. We just need to keep track of the removal task and only install/confirm the NO_REBALANCE phase once all the entries that we don't own have been removed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9021) Remote query: add option to disable default/legacy indexing per schema file

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9021?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9021: ---------------------------------- Fix Version/s: 9.3.0.Beta1 (was: 9.3.0.Alpha1) > Remote query: add option to disable default/legacy indexing per schema file > --------------------------------------------------------------------------- > > Key: ISPN-9021 > URL: https://issues.jboss.org/browse/ISPN-9021 > Project: Infinispan > Issue Type: Enhancement > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.3.0.Beta1, 9.3.0.Final > > > All types that are not annotated are currently fully indexed for backward compat with first version of remote query (which did not have protobuf annotations to control indexing). > This behaviour is very inefficient and confusing for users that do not intend to use indexing (non-indexed query works anyway). > Given the history of this behaviour we cannot remove it until next major version. Until then we can offer the choice of disabling it per each schema file via a boolean protobuf file-level option named 'enable_legacy_indexing', which when absent is considered to default to true. Setting it to false will disable indexing of types that do not have indexing annotations. > Whenever an entry is indexed using default indexing a warning will be logged in order to motivate people to switch to using proper annotations. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2018