December 2018 - infinispan-issues

[JBoss JIRA] (ISPN-9316) Rewrite Ickle parser on ANTLR 4

by Galder Zamarreño (Jira)

[ https://issues.jboss.org/browse/ISPN-9316?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9316: ----------------------------------- Fix Version/s: 9.4.5.Final (was: 9.4.4.Final) > Rewrite Ickle parser on ANTLR 4 > ------------------------------- > > Key: ISPN-9316 > URL: https://issues.jboss.org/browse/ISPN-9316 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Major > Fix For: 9.4.5.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9291) BasePartitionHandlingTest.Partition.installMergeView() doesn't compute the merge digest

by Galder Zamarreño (Jira)

[ https://issues.jboss.org/browse/ISPN-9291?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9291: ----------------------------------- Fix Version/s: 9.4.5.Final (was: 9.4.4.Final) > BasePartitionHandlingTest.Partition.installMergeView() doesn't compute the merge digest > --------------------------------------------------------------------------------------- > > Key: ISPN-9291 > URL: https://issues.jboss.org/browse/ISPN-9291 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.3.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Labels: testsuite_stability > Fix For: 9.4.5.Final > > > The partition handling tests use {{BasePartitionHandlingTest.Partition.installMergeView(view1, view2)}} to install the merge view without waiting for {{MERGE3}} to run, making them much faster. Unfortunately, the implementation is incorrect: {{GMS.installView(view)}} only works for regular views, merge views need to be installed with {{GMS.installView(mergeView, digest)}}. > The result is that the nodes that got isolated from the coordinator request the retransmission of all the {{NAKACK2}} messages (including view updates) since the cluster first started. The isolated nodes cannot install the merge view until they deliver all the older messages (even without knowing whether they're OOB or not). But if {{STABLE}} ran and cleared a range of messages already, the retransmission request cannot be satisfied, so the view updates will never be delivered. > This is easily reproducible in {{CrashedNodeDuringConflictResolutionTest}} if we add a delay before updating the topology in {{StateConsumerImpl}}. The test installs the merge view manually, but then kills NodeC and expects the cluster to install the new view automatically. NodeD can't install the new view because it's waiting for earlier messages from NodeA: > {noformat} > 18:27:13,054 INFO (testng-test:[]) [TestSuiteProgress] Test starting: org.infinispan.conflict.impl.CrashedNodeDuringConflictResolutionTest.testPartitionMergePolicy[DIST_SYNC] > 18:27:13,640 DEBUG (testng-test:[]) [GMS] test-NodeA-39513: installing view MergeView::[test-NodeA-39513|10] (4) [test-NodeA-39513, test-NodeB-9439, test-NodeC-43706, test-NodeD-59078], 2 subgroups: [test-NodeA-39513|8] (2) [test-NodeA-39513, test-NodeB-9439], [test-NodeC-43706|9] (2) [test-NodeC-43706, test-NodeD-59078] > 18:27:13,674 DEBUG (testng-test:[]) [GMS] test-NodeD-59078: installing view MergeView::[test-NodeA-39513|10] (4) [test-NodeA-39513, test-NodeB-9439, test-NodeC-43706, test-NodeD-59078], 2 subgroups: [test-NodeA-39513|8] (2) [test-NodeA-39513, test-NodeB-9439], [test-NodeC-43706|9] (2) [test-NodeC-43706, test-NodeD-59078] > 18:27:13,828 TRACE (jgroups-7,test-NodeD-59078:[]) [NAKACK2] test-NodeD-59078: sending XMIT_REQ ((1): {50}) to test-NodeA-39513 > 18:27:13,966 TRACE (Timer runner-1,test-NodeD-59078:[]) [NAKACK2] test-NodeD-59078: sending XMIT_REQ ((49): {1-49}) to test-NodeA-39513 > 18:27:14,067 TRACE (Timer runner-1,test-NodeD-59078:[]) [NAKACK2] test-NodeD-59078: sending XMIT_REQ ((45): {1-45}) to test-NodeA-39513 > 18:27:14,504 DEBUG (testng-test:[]) [DefaultCacheManager] Stopping cache manager ISPN on test-NodeC-43706 > 18:27:18,642 TRACE (VERIFY_SUSPECT.TimerThread-89,test-NodeA-39513:[]) [GMS] test-NodeA-39513: joiners=[], suspected=[test-NodeC-43706], leaving=[], new view: [test-NodeA-39513|11] (3) [test-NodeA-39513, test-NodeB-9439, test-NodeD-59078] > 18:27:18,643 TRACE (VERIFY_SUSPECT.TimerThread-89,test-NodeA-39513:[]) [GMS] test-NodeA-39513: mcasting view [test-NodeA-39513|11] (3) [test-NodeA-39513, test-NodeB-9439, test-NodeD-59078] > 18:27:18,646 DEBUG (VERIFY_SUSPECT.TimerThread-89,test-NodeA-39513:[]) [GMS] test-NodeA-39513: installing view [test-NodeA-39513|11] (3) [test-NodeA-39513, test-NodeB-9439, test-NodeD-59078] > 18:27:18,652 TRACE (VERIFY_SUSPECT.TimerThread-89,test-NodeA-39513:[]) [TCP_NIO2] test-NodeA-39513: sending msg to null, src=test-NodeA-39513, headers are GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=63], TP: [cluster_name=ISPN] > 18:27:18,656 TRACE (jgroups-20,test-NodeA-39513:[]) [TCP_NIO2] test-NodeA-39513: received [dst: test-NodeA-39513, src: test-NodeB-9439 (3 headers), size=0 bytes, flags=OOB|INTERNAL], headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=100, TP: [cluster_name=ISPN] > 18:27:20,554 TRACE (Timer runner-1,test-NodeD-59078:[]) [NAKACK2] test-NodeD-59078: sending XMIT_REQ ((45): {1-45}) to test-NodeA-39513 > 18:27:20,653 WARN (VERIFY_SUSPECT.TimerThread-89,test-NodeA-39513:[]) [GMS] test-NodeA-39513: failed to collect all ACKs (expected=2) for view [test-NodeA-39513|11] after 2000ms, missing 1 ACKs from (1) test-NodeD-59078 > 18:27:20,656 TRACE (Timer runner-1,test-NodeD-59078:[]) [NAKACK2] test-NodeD-59078: sending XMIT_REQ ((45): {1-45}) to test-NodeA-39513 > 18:27:20,756 TRACE (Timer runner-1,test-NodeD-59078:[]) [NAKACK2] test-NodeD-59078: sending XMIT_REQ ((45): {1-45}) to test-NodeA-39513 > ... > 18:28:14,412 TRACE (Timer runner-1,test-NodeD-59078:[]) [NAKACK2] test-NodeD-59078: sending XMIT_REQ ((45): {1-45}) to test-NodeA-39513 > 18:28:14,513 TRACE (Timer runner-1,test-NodeD-59078:[]) [NAKACK2] test-NodeD-59078: sending XMIT_REQ ((45): {1-45}) to test-NodeA-39513 > 18:28:14,589 ERROR (testng-test:[]) [TestSuiteProgress] Test failed: org.infinispan.conflict.impl.CrashedNodeDuringConflictResolutionTest.testPartitionMergePolicy[DIST_SYNC] > java.lang.RuntimeException: Cache ___defaultcache timed out waiting for rebalancing to complete on node test-NodeA-39513, current topology is CacheTopology{id=21, phase=CONFLICT_RESOLUTION, rebalanceId=7, currentCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (3)[test-NodeD-59078: 256+0, test-NodeA-39513: 0+256, test-NodeB-9439: 0+256]}, pendingCH=null, unionCH=null, actualMembers=[test-NodeD-59078, test-NodeA-39513, test-NodeB-9439], persistentUUIDs=[828108c4-4251-49fc-9481-ff6392bea9fb, 1d4b6f07-b71b-41a1-adfb-abbe68944a9f, 3a1ece05-c282-433e-9eb5-7b3e0f1932aa]}. rebalanceInProgress=true, currentChIsBalanced=true > at org.infinispan.test.TestingUtil.waitForNoRebalance(TestingUtil.java:392) ~[test-classes/:?] > at org.infinispan.conflict.impl.CrashedNodeDuringConflictResolutionTest.performMerge(CrashedNodeDuringConflictResolutionTest.java:113) ~[test-classes/:?] > at org.infinispan.conflict.impl.BaseMergePolicyTest.testPartitionMergePolicy(BaseMergePolicyTest.java:137) ~[test-classes/:?] > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9270) ClusteredLockWith2NodesTest.testTryLockAndKillLocking random failures

by Galder Zamarreño (Jira)

[ https://issues.jboss.org/browse/ISPN-9270?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9270: ----------------------------------- Fix Version/s: 9.4.5.Final (was: 9.4.4.Final) > ClusteredLockWith2NodesTest.testTryLockAndKillLocking random failures > --------------------------------------------------------------------- > > Key: ISPN-9270 > URL: https://issues.jboss.org/browse/ISPN-9270 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.3.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 9.4.5.Final > > > The test stops the coordinator A of a 2-node cluster \[A, B\], and then verifies that B stays available. > Unfortunately that doesn't always happen: A tries to install topology \[B\] before shutting down, but B might receive it too late and reject it. If B expects members \[A, B\] and sees only B, the cache will enter degraded mode: > {noformat} > 19:04:05,863 INFO (jgroups-8,Test-NodeB-21374:[org.infinispan.LOCKS]) [CLUSTER] [Context=org.infinispan.LOCKS] ISPN100008: Updating cache members list [Test-NodeD-51051], topology id 7 > 19:04:05,863 TRACE (jgroups-4,Test-NodeD-51051:[]) [JGroupsTransport] Test-NodeD-51051 received command from Test-NodeB-21374: CacheTopologyControlCommand{cache=org.infinispan.LOCKS, type=CH_UPDATE, sender=Test-NodeB-21374, joinInfo=null, topologyId=7, rebalanceId=2, currentCH=ReplicatedConsistentHash{ns = 256, owners = (1)[Test-NodeD-51051: 256]}, pendingCH=null, availabilityMode=AVAILABLE, phase=NO_REBALANCE, actualMembers=[Test-NodeD-51051], throwable=null, viewId=1} > 19:04:05,880 INFO (jgroups-4,Test-NodeD-51051:[]) [CLUSTER] ISPN000094: Received new cluster view for channel ISPN: [Test-NodeD-51051|2] (1) [Test-NodeD-51051] > 19:04:05,884 DEBUG (stateTransferExecutor-thread-Test-NodeD-p101-t1:[Merge-2]) [ClusterCacheStatus] Recovered 1 partition(s) for cache org.infinispan.LOCKS: [CacheTopology{id=6, phase=NO_REBALANCE, rebalanceId=2, currentCH=ReplicatedConsistentHash{ns = 256, owners = (2)[Test-NodeB-21374: 124, Test-NodeD-51051: 132]}, pendingCH=null, unionCH=null, actualMembers=[Test-NodeD-51051], persistentUUIDs=[6ac3a341-5af4-4aa2-ae7b-a4183d02d959]}] > 19:04:05,884 WARN (stateTransferExecutor-thread-Test-NodeD-p101-t1:[Merge-2]) [CLUSTER] [Context=org.infinispan.LOCKS] ISPN000320: After merge (or coordinator change), cache still hasn't recovered a majority of members and must stay in degraded mode. Current members are [Test-NodeD-51051], lost members are [Test-NodeB-21374], stable members are [Test-NodeB-21374, Test-NodeD-51051] > 19:04:05,885 INFO (stateTransferExecutor-thread-Test-NodeD-p101-t1:[Merge-2]) [CLUSTER] [Context=org.infinispan.LOCKS] ISPN100011: Entering availability mode DEGRADED_MODE, topology id 8 > 19:04:05,941 DEBUG (transport-thread-Test-NodeD-p100-t2:[Topology-org.infinispan.LOCKS]) [LocalTopologyManagerImpl] Ignoring topology 7 for cache org.infinispan.LOCKS from old coordinator Test-NodeB-21374 > 19:04:06,024 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.lock.ClusteredLockWith2NodesTest.testTryLockAndKillLocking > java.lang.Error: java.util.concurrent.ExecutionException: java.lang.Error: java.util.concurrent.ExecutionException: org.infinispan.lock.exception.ClusteredLockException: org.infinispan.partitionhandling.AvailabilityException: ISPN000306: Key 'ClusteredLockKey{name=Test}' is not available. Not all owners are in this partition > at org.infinispan.functional.FunctionalTestUtils.await(FunctionalTestUtils.java:47) ~[infinispan-core-9.3.0-SNAPSHOT-tests.jar:9.3.0-SNAPSHOT] > at org.infinispan.lock.ClusteredLockWith2NodesTest.testTryLockAndKillLocking(ClusteredLockWith2NodesTest.java:49) ~[test-classes/:?] > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9699) Cluster member owning no data

by Galder Zamarreño (Jira)

[ https://issues.jboss.org/browse/ISPN-9699?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9699: ----------------------------------- Fix Version/s: 9.4.5.Final (was: 9.4.4.Final) > Cluster member owning no data > ----------------------------- > > Key: ISPN-9699 > URL: https://issues.jboss.org/browse/ISPN-9699 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 9.4.1.Final > Reporter: Thomas Segismont > Assignee: Katia Aresti > Priority: Major > Fix For: 10.0.0.Beta1, 9.4.5.Final > > > Currently, you can set {{capacity-factor}} to zero on a cache if you don't want a node to own any segment. > If you want a node to own no data at all, you could set this property on all declared caches. But this wouldn't work for internal caches anyway (locks, counters). > It would be nice to have a global switch. > This would be useful when your app needs to be a cluster member for discovery/membership but is deployed mostly for processing. Indeed, when such nodes are added/removed from the cluster: > * there would be no data loss > * the cluster would be back in healthy state faster as no data would be moved around. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9677) Non-transactional queries don't update the query cache

by Galder Zamarreño (Jira)

[ https://issues.jboss.org/browse/ISPN-9677?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9677: ----------------------------------- Fix Version/s: 9.4.5.Final (was: 9.4.4.Final) > Non-transactional queries don't update the query cache > ------------------------------------------------------ > > Key: ISPN-9677 > URL: https://issues.jboss.org/browse/ISPN-9677 > Project: Infinispan > Issue Type: Bug > Components: Hibernate Cache > Affects Versions: 9.4.1.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Major > Fix For: 10.0.0.Alpha1, 9.4.5.Final > > > This is affecting the Hibernate second-level cache simple tutorials where queries are executed outside transactions. > The problem is that the new integration for the query results (result of ISPN-9075) does not verify if there's an on-going transaction before registering a transaction completed synchronization where the query cache is updated. > As a result, when a non-transactional query happens, the transaction synchronization callback does not happen and the query cache is not updated. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9657) Multimap jar is not OSGi compliant

by Galder Zamarreño (Jira)

[ https://issues.jboss.org/browse/ISPN-9657?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9657: ----------------------------------- Fix Version/s: 9.4.5.Final (was: 9.4.4.Final) > Multimap jar is not OSGi compliant > ---------------------------------- > > Key: ISPN-9657 > URL: https://issues.jboss.org/browse/ISPN-9657 > Project: Infinispan > Issue Type: Bug > Components: Multimap > Affects Versions: 9.4.0.Final > Reporter: Alain Picard > Assignee: Katia Aresti > Priority: Major > Fix For: 10.0.0.Beta1, 9.4.5.Final > > > Due to issues related to using the embedded jar (see [here|https://developer.jboss.org/message/986042#986042], when switching to individual jars, the multimap jar (infinispan-multimap-9.4.0.Final.jar) doesn't provide a valid OSGi manifest. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9610) Expose PersistenceManager availability via JMX

by Galder Zamarreño (Jira)

[ https://issues.jboss.org/browse/ISPN-9610?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9610: ----------------------------------- Fix Version/s: 9.4.5.Final (was: 9.4.4.Final) > Expose PersistenceManager availability via JMX > ---------------------------------------------- > > Key: ISPN-9610 > URL: https://issues.jboss.org/browse/ISPN-9610 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management > Affects Versions: 9.4.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 9.4.5.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9587) Key Transformer registration via config

by Galder Zamarreño (Jira)

[ https://issues.jboss.org/browse/ISPN-9587?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9587: ----------------------------------- Fix Version/s: 9.4.5.Final (was: 9.4.4.Final) > Key Transformer registration via config > --------------------------------------- > > Key: ISPN-9587 > URL: https://issues.jboss.org/browse/ISPN-9587 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying, Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Major > Fix For: 9.4.5.Final > > > Under indexing config element: > {code} > <key-transformers> > <key-transformer key="org.infinispan.query.test.CustomKey" transformer="org.infinispan.query.test.CustomTransformer"/> > </key-transformers> > {code} > and also via the config builder API. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9582) Lifespan/MaxIdle = 0 from Hot Rod behaviour is inconsistent with embedded

by Galder Zamarreño (Jira)

[ https://issues.jboss.org/browse/ISPN-9582?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9582: ----------------------------------- Fix Version/s: 9.4.5.Final (was: 9.4.4.Final) > Lifespan/MaxIdle = 0 from Hot Rod behaviour is inconsistent with embedded > ------------------------------------------------------------------------- > > Key: ISPN-9582 > URL: https://issues.jboss.org/browse/ISPN-9582 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.4.0.CR3 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 9.4.5.Final > > > In embedded mode, specifying 0 for lifespan or maxIdle results in immediate expiration. > In Hot Rod, however, 0 results in the entry using the default server-side expiration. This was done in order to not introduce a protocol change at the time. > The 2.2 protocol introduced timeunit support with special values for default and infinity. > We should therefore not override a user-specified value of 0 with "default". -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9578) Move HR wire docs to contributing guide

by Galder Zamarreño (Jira)

[ https://issues.jboss.org/browse/ISPN-9578?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9578: ----------------------------------- Fix Version/s: 9.4.5.Final (was: 9.4.4.Final) > Move HR wire docs to contributing guide > --------------------------------------- > > Key: ISPN-9578 > URL: https://issues.jboss.org/browse/ISPN-9578 > Project: Infinispan > Issue Type: Task > Components: Documentation-Core > Affects Versions: 9.4.0.CR3 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 9.4.5.Final > > > The Hot Rod wire protocol has no place in the user guide. It should be moved to the contributing guide. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2018