January 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5481) ConfigurationOverrideTest random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5481?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5481: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.2.0.Final Resolution: Done > ConfigurationOverrideTest random failures > ----------------------------------------- > > Key: ISPN-5481 > URL: https://issues.jboss.org/browse/ISPN-5481 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 8.2.0.Beta1, 8.2.0.Final > > > {{ConfigurationOverrideTest}} uses the default global configuration, and it fails when another test has already registered a cache manager MBean in JMX with the same name: > {noformat} > org.infinispan.jmx.JmxDomainConflictException: ISPN000034: There's already a JMX MBean instance type=CacheManager,name="DefaultCacheManager" already registered under 'org.infinispan' JMX domain. If you want to allow multiple instances configured with same JMX domain enable 'allowDuplicateDomains' attribute in 'globalJmxStatistics' config element > at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:51) > at org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:79) > at org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:73) > at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:37) > at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:41) > at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:625) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:218) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:199) > at org.infinispan.configuration.ConfigurationOverrideTest.testOverrideWithStore(ConfigurationOverrideTest.java:80) > {noformat} > We should verify the other tests as well, to make sure they all use the {{PerThreadMBeanServerLookup}} and/or a unique JMX domain. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6106) FilterConditionEndContext.between(from, to) should check args are Comparable

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6106?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6106: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > FilterConditionEndContext.between(from, to) should check args are Comparable > ---------------------------------------------------------------------------- > > Key: ISPN-6106 > URL: https://issues.jboss.org/browse/ISPN-6106 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying > Affects Versions: 8.0.2.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.2.0.Beta1, 8.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6107) State transfer should not fetch segments that were added during a rebalance

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6107?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6107: ------------------------------- Status: Open (was: New) > State transfer should not fetch segments that were added during a rebalance > --------------------------------------------------------------------------- > > Key: ISPN-6107 > URL: https://issues.jboss.org/browse/ISPN-6107 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.0.Beta1 > > > When the last owner of a segment leaves the cache, the coordinator will update the consistent hash and replace that owner with {{numOwners}} owners (so that a segment always has at least 1 owner). If there is a rebalance in progress, it could be that both the current and the pending CH lost all the owners of a segment, and the coordinator will assign new owners in both CHs (not necessarily the same). > Sometimes, this causes tests that create clusters with many nodes to spend a lot of time shutting down the cluster. Here's an example: > # Cluster ABCDE, coordinator A, topology id = 0, currentCH = \{0: CD, 1: BC\}, pendingCH = null > # D leaves > # A broadcasts a REBALANCE_START command with topology id 1, members = ABCE, currentCH = \{0: C, 1: BC\}, pendingCH = \{0: BC, 1: BC\} > # A and E confirm that they finished the rebalance > # C leaves before sending the data for segment 0 to B > # A broadcasts a CH_UPDATE command with topology id 2, members = ABE, currentCH = \{0: AE, 1: B\}, pendingCH = \{0: B, 1: B\} > # A now owns segment 0 in the writeCH (which is the union of currentCH and pendingCH). > # A tries to request segment 0 from the other owner in the currentCH, E > # B confirms that it finished the rebalance > # A broadcasts a new topology: topology id 3, currentCH = \{0: B, 1: B\}, pendingCH = null > # E installs topology 3, and throws an IllegalArgumentException when handling A's request for segments > # A is not able to install topology 3, because it requests the transactions data while holding the lock on the LocalCacheStatus > # A receives the IllegalArgumentException from E and retries. But because it still has the old topology, it retries on E ad infinitum - using a lot of CPU in the process. > A requesting segment 0 from E is not a problem in itself - normally E would just send back an empty set of transactions and entries. The problem is that the cluster is able to install a new topology, because A already confirmed receiving all the data, but A is stuck with the old topology. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6107) State transfer should not fetch segments that were added during a rebalance

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6107?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6107: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3962 > State transfer should not fetch segments that were added during a rebalance > --------------------------------------------------------------------------- > > Key: ISPN-6107 > URL: https://issues.jboss.org/browse/ISPN-6107 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.0.Beta1 > > > When the last owner of a segment leaves the cache, the coordinator will update the consistent hash and replace that owner with {{numOwners}} owners (so that a segment always has at least 1 owner). If there is a rebalance in progress, it could be that both the current and the pending CH lost all the owners of a segment, and the coordinator will assign new owners in both CHs (not necessarily the same). > Sometimes, this causes tests that create clusters with many nodes to spend a lot of time shutting down the cluster. Here's an example: > # Cluster ABCDE, coordinator A, topology id = 0, currentCH = \{0: CD, 1: BC\}, pendingCH = null > # D leaves > # A broadcasts a REBALANCE_START command with topology id 1, members = ABCE, currentCH = \{0: C, 1: BC\}, pendingCH = \{0: BC, 1: BC\} > # A and E confirm that they finished the rebalance > # C leaves before sending the data for segment 0 to B > # A broadcasts a CH_UPDATE command with topology id 2, members = ABE, currentCH = \{0: AE, 1: B\}, pendingCH = \{0: B, 1: B\} > # A now owns segment 0 in the writeCH (which is the union of currentCH and pendingCH). > # A tries to request segment 0 from the other owner in the currentCH, E > # B confirms that it finished the rebalance > # A broadcasts a new topology: topology id 3, currentCH = \{0: B, 1: B\}, pendingCH = null > # E installs topology 3, and throws an IllegalArgumentException when handling A's request for segments > # A is not able to install topology 3, because it requests the transactions data while holding the lock on the LocalCacheStatus > # A receives the IllegalArgumentException from E and retries. But because it still has the old topology, it retries on E ad infinitum - using a lot of CPU in the process. > A requesting segment 0 from E is not a problem in itself - normally E would just send back an empty set of transactions and entries. The problem is that the cluster is able to install a new topology, because A already confirmed receiving all the data, but A is stuck with the old topology. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5481) ConfigurationOverrideTest random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5481?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5481: ------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/3877, https://github.com/infinispan/infinispan/pull/3961 (was: https://github.com/infinispan/infinispan/pull/3877) > ConfigurationOverrideTest random failures > ----------------------------------------- > > Key: ISPN-5481 > URL: https://issues.jboss.org/browse/ISPN-5481 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 8.2.0.Beta1 > > > {{ConfigurationOverrideTest}} uses the default global configuration, and it fails when another test has already registered a cache manager MBean in JMX with the same name: > {noformat} > org.infinispan.jmx.JmxDomainConflictException: ISPN000034: There's already a JMX MBean instance type=CacheManager,name="DefaultCacheManager" already registered under 'org.infinispan' JMX domain. If you want to allow multiple instances configured with same JMX domain enable 'allowDuplicateDomains' attribute in 'globalJmxStatistics' config element > at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:51) > at org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:79) > at org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:73) > at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:37) > at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:41) > at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:625) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:218) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:199) > at org.infinispan.configuration.ConfigurationOverrideTest.testOverrideWithStore(ConfigurationOverrideTest.java:80) > {noformat} > We should verify the other tests as well, to make sure they all use the {{PerThreadMBeanServerLookup}} and/or a unique JMX domain. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5481) ConfigurationOverrideTest random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5481?page=com.atlassian.jira.plugin.... ] Dan Berindei reopened ISPN-5481: -------------------------------- Found more test methods in {{SecurityXmlFileParsingTest}}, {{ConfigurationOverrideTest}}, and {{ConfigurationUnitTest}} that were using {{new DefaultCacheManager(new GlobalConfigurationBuilder().build())}}. > ConfigurationOverrideTest random failures > ----------------------------------------- > > Key: ISPN-5481 > URL: https://issues.jboss.org/browse/ISPN-5481 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 8.2.0.Beta1 > > > {{ConfigurationOverrideTest}} uses the default global configuration, and it fails when another test has already registered a cache manager MBean in JMX with the same name: > {noformat} > org.infinispan.jmx.JmxDomainConflictException: ISPN000034: There's already a JMX MBean instance type=CacheManager,name="DefaultCacheManager" already registered under 'org.infinispan' JMX domain. If you want to allow multiple instances configured with same JMX domain enable 'allowDuplicateDomains' attribute in 'globalJmxStatistics' config element > at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:51) > at org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:79) > at org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:73) > at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:37) > at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:41) > at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:625) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:218) > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:199) > at org.infinispan.configuration.ConfigurationOverrideTest.testOverrideWithStore(ConfigurationOverrideTest.java:80) > {noformat} > We should verify the other tests as well, to make sure they all use the {{PerThreadMBeanServerLookup}} and/or a unique JMX domain. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6118) CacheNotifierImplInitialTransferDistTest random failures

by Dan Berindei (JIRA)

Dan Berindei created ISPN-6118: ---------------------------------- Summary: CacheNotifierImplInitialTransferDistTest random failures Key: ISPN-6118 URL: https://issues.jboss.org/browse/ISPN-6118 Project: Infinispan Issue Type: Bug Components: Test Suite - Core Affects Versions: 8.1.0.Final Reporter: Dan Berindei Fix For: 8.2.0.Beta1 The failures are probably related to the default consistent hash factory change. {noformat} 18:54:56,255 ERROR (testng-CacheNotifierImplInitialTransferDistTest:) [UnitTestTestNGListener] Test testCreateAfterIterationBeganAndSegmentNotCompleteValueNonOwnerClustered(org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest) failed. java.util.concurrent.TimeoutException: Timed out waiting for event pre_complete_segment_invoked at org.infinispan.test.fwk.CheckPoint.awaitStrict(CheckPoint.java:43) ~[test-classes/:?] at org.infinispan.test.fwk.CheckPoint.awaitStrict(CheckPoint.java:33) ~[test-classes/:?] at org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest.testIterationBeganAndSegmentNotComplete(CacheNotifierImplInitialTransferDistTest.java:519) ~[test-classes/:?] at org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest.testCreateAfterIterationBeganAndSegmentNotCompleteValueNonOwnerClustered(CacheNotifierImplInitialTransferDistTest.java:622) ~[test-classes/:?] {noformat} {noformat} 18:55:06,637 ERROR (testng-CacheNotifierImplInitialTransferDistTest:) [UnitTestTestNGListener] Test testCreateAfterIterationBeganAndSegmentNotCompleteValueOwnerClustered(org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest) failed. java.util.concurrent.TimeoutException: Timed out waiting for event pre_complete_segment_invoked at org.infinispan.test.fwk.CheckPoint.awaitStrict(CheckPoint.java:43) ~[test-classes/:?] at org.infinispan.test.fwk.CheckPoint.awaitStrict(CheckPoint.java:33) ~[test-classes/:?] at org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest.testIterationBeganAndSegmentNotComplete(CacheNotifierImplInitialTransferDistTest.java:519) ~[test-classes/:?] at org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest.testCreateAfterIterationBeganAndSegmentNotCompleteValueOwnerClustered(CacheNotifierImplInitialTransferDistTest.java:633) ~[test-classes/:?] {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6117) Management console - cache configuration can not be be edited

by Roman Macor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6117?page=com.atlassian.jira.plugin.... ] Roman Macor updated ISPN-6117: ------------------------------ Summary: Management console - cache configuration can not be be edited (was: Management console - cache configuration can't be be edited) > Management console - cache configuration can not be be edited > ------------------------------------------------------------- > > Key: ISPN-6117 > URL: https://issues.jboss.org/browse/ISPN-6117 > Project: Infinispan > Issue Type: Bug > Components: Console > Reporter: Roman Macor > Assignee: Vladimir Blagojevic > > go to Caches tab -> click on container -> click on cache -> actions > There is no option to edit configuration, only option to view configuration. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6117) Management console - cache configuration can't be be edited

by Roman Macor (JIRA)

Roman Macor created ISPN-6117: --------------------------------- Summary: Management console - cache configuration can't be be edited Key: ISPN-6117 URL: https://issues.jboss.org/browse/ISPN-6117 Project: Infinispan Issue Type: Bug Components: Console Reporter: Roman Macor Assignee: Vladimir Blagojevic go to Caches tab -> click on container -> click on cache -> actions There is no option to edit configuration, only option to view configuration. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6116) query-dsl module shoud use jboss-logging

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6116?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-6116: ------------------------------------- The support is there, just needs to be used for all messages and exceptions. > query-dsl module shoud use jboss-logging > ---------------------------------------- > > Key: ISPN-6116 > URL: https://issues.jboss.org/browse/ISPN-6116 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.1.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.2.0.Beta1, 8.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2016