February 2013 - infinispan-issues

[JBoss JIRA] (ISPN-2376) KeyAffinityServiceImpl.getKeyForAddress() can loop forever when DefaultConsistentHash has numSegments < numNodes

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2376?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2376: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > KeyAffinityServiceImpl.getKeyForAddress() can loop forever when DefaultConsistentHash has numSegments < numNodes > ---------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2376 > URL: https://issues.jboss.org/browse/ISPN-2376 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.0.Beta1 > Reporter: Scott Marlow > Assignee: Dan Berindei > Fix For: 5.2.2, 5.3.0.Final > > > I instrumented KeyAffinityServiceImpl and DefaultConsistentHash to show why KeyAffinityServiceImpl is looping forever when running the AS7 clustered tests with some recent changes that aren't committed yet. We are hoping to get through this failure so we can get clustered tests running again more completely on our continuous test server (lightning). > We have two nodes running in the AS cluster, node-0/web and node-1/web. > In my recent test run, I stopped the test after it was stuck for a while. Below is some of the instrumented logging output. > {quote} > KeyAffinityServiceImpl interestedInAddress() check, for address: node-1/web, filter.contains(address) returns false, filter contents [node-0/web] > . > . > . > KeyAffinityServiceImpl.getKeyForAddress() loop # 1455775 will loop again since result is null, queue [], address node-0/web > {quote} > We are using address "node-1/web" because that is passed into the DefaultConsistentHash constructor segmentOwners parameter (element zero). > Later, address=node-1/web is the primary owner of the consistent hash (hash=DefaultConsistentHash{numSegments=1, numOwners=2, members=[node-1/web, node-0/web], segmentOwners={0: 0 1}). > I'm still collecting information and want to get a little more. > Let me know if there is anything that you would like to see. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2264) DistL1WriteSkewTest.testSharedCounter failing randomly

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2264?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2264: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > DistL1WriteSkewTest.testSharedCounter failing randomly > ------------------------------------------------------ > > Key: ISPN-2264 > URL: https://issues.jboss.org/browse/ISPN-2264 > Project: Infinispan > Issue Type: Bug > Reporter: Galder Zamarreño > Assignee: Adrian Nistor > Labels: testsuite_stability > Fix For: 5.2.2, 5.3.0.Alpha1 > > > {code}Failed tests: > testSharedCounter(org.infinispan.container.versioning.DistL1WriteSkewTest): > Timed out waiting for updater threads{code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2278) Implicit transaction enabling during configuration fails

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2278?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2278: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > Implicit transaction enabling during configuration fails > -------------------------------------------------------- > > Key: ISPN-2278 > URL: https://issues.jboss.org/browse/ISPN-2278 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 5.1.6.FINAL > Reporter: Thomas Fromm > Assignee: Tristan Tarrant > Fix For: 5.2.2, 5.3.0.Final > > > The implicit enabling of transaction support does not work in all cases described in TransactionMode Javadoc inside the current configuration API. > - transactionManagerLookup is explicit configured > This works not in programmatic. > - enabled batching > When using XML configuration, this will not work, when only <invocationBatching> element and no <transaction> element is used. > At ConfigurationBuilderHolder.newConfigurationBuilder(...) the default cache config is used as base for the new named cache. Since build() is called, the TransactionConfiguration is set to NON_TRANSACTIONAL in the Configuration template used for the new ConfigurationBuilder. Later then any if(transactionMode == null)-related conditions in TransactionConfigurationBuilder will fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2257) SimpleCacheRecoveryAdminTest.testForceCommitOnOtherNode still randomly failing

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2257?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2257: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > SimpleCacheRecoveryAdminTest.testForceCommitOnOtherNode still randomly failing > ------------------------------------------------------------------------------- > > Key: ISPN-2257 > URL: https://issues.jboss.org/browse/ISPN-2257 > Project: Infinispan > Issue Type: Bug > Reporter: Galder Zamarreño > Assignee: Mircea Markus > Labels: testsuite_stability > Fix For: 5.2.2, 5.3.0.Alpha1 > > > The issue is failing again in master: > {code}Failed tests: testForceCommitOnOtherNode(org.infinispan.tx.recovery.admin.SimpleCacheRecoveryAdminTest): expected:<false> but was:<true>{code} > Unfortunately I don't have any logs. > No idea if this is related to NBST at all :( -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2174) CommandAwareRpcDispatcher swallows thread interruptions

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2174?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2174: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > CommandAwareRpcDispatcher swallows thread interruptions > ------------------------------------------------------- > > Key: ISPN-2174 > URL: https://issues.jboss.org/browse/ISPN-2174 > Project: Infinispan > Issue Type: Bug > Components: RPC > Affects Versions: 5.1.5.FINAL > Reporter: Michal Linhard > Assignee: Mircea Markus > Labels: jdg, jdg6 > Fix For: 5.2.2, 5.3.0.Final > > > When interruption happens in FutureCollator.getResponseList() method > see > https://github.com/infinispan/infinispan/blob/5.1.x/core/src/main/java/or... > it is ignored and later wrongly dealt with as TimeoutException > (The original exception is not even set as cause anywhere) > This disables possibility of interrupting some cache operations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2504) WriteSkew check fails for entries which are inserted first time

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2504?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2504: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > WriteSkew check fails for entries which are inserted first time > --------------------------------------------------------------- > > Key: ISPN-2504 > URL: https://issues.jboss.org/browse/ISPN-2504 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency > Affects Versions: 5.2.0.Beta3 > Reporter: Radim Vansa > Assignee: Pedro Ruivo > Fix For: 5.2.2, 5.3.0.Final > > > If optimistic locking and write skew check are configured and there are two concurrent transactions performing > {code} > read(key) -> null > write(key, value) > {code} > one of them should fail (if both read {{null}}). However, both transaction succeed in this case. The reason is that that the {{VersionedPrepareCommand}} has {{null}} version for the key (because it was null) but in {{WriteSkewHelper.performWriteSkewCheckAndReturnNewVersions}} there is > {code} > EntryVersion versionSeen = prepareCommand.getVersionsSeen().get(k); > if (versionSeen != null) entry.setVersion(versionSeen); > {code} > As the {{entry}} contains the version injected into context from {{dataContainer}} in {{EntryFactoryImpl.wrapInternalCacheEntryForPut}} lately during the {{VersionedPrepareCommand}} execution, and the version is not overwritten from the {{getVersionsSeen()}} value (as this is null), the performWriteSkewCheck does not report this entry as changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2509) org.infinispan.client.hotrod.PingOnStartupTest.testTopologyFetched randomly fails

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2509?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2509: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > org.infinispan.client.hotrod.PingOnStartupTest.testTopologyFetched randomly fails > --------------------------------------------------------------------------------- > > Key: ISPN-2509 > URL: https://issues.jboss.org/browse/ISPN-2509 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Anna Manukyan > Assignee: Mircea Markus > Labels: testsuite_stability > Fix For: 5.2.2, 5.3.0.Alpha1 > > > The test failed on Solaris11_x64 sparcs. > The log is available here: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... > The bug doesn't appear when the test is run separately. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2477) AsyncStore shutdown can leak threads

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2477?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2477: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > AsyncStore shutdown can leak threads > ------------------------------------ > > Key: ISPN-2477 > URL: https://issues.jboss.org/browse/ISPN-2477 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.0.Beta3 > Reporter: Adrian Nistor > Assignee: Galder Zamarreño > Fix For: 5.2.2, 5.3.0.Final > > > AsyncStore stop() should take care that all threads (coordinator and workers) are shut down. Right now there could be worker threads left hanging and the coordinator thread waiting forever for them to end. > coordinator.join(shutdownTimeout) in AsyncStore.stop() could time out and both coordinator and worker thread will leak in this case. > We must ensure the coordinator is terminated and the ExecutorService used for worker threads is also shut down when we exit AsyncStore.stop(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2441) Some core interceptors trigger custom interceptor error message

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2441?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2441: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > Some core interceptors trigger custom interceptor error message > --------------------------------------------------------------- > > Key: ISPN-2441 > URL: https://issues.jboss.org/browse/ISPN-2441 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 5.2.0.Beta2 > Reporter: Dan Berindei > Assignee: Manik Surtani > Fix For: 5.2.2, 5.3.0.Final > > > I'm not sure if this is really a problem or if it's just a superfluous error message, but I'm seeing about 6000 of these during a typical test suite run: > {noformat} > ISPN000173: Custom interceptor org.infinispan.interceptors.ActivationInterceptor has used @Inject, @Start or @Stop. These methods will not be processed. Please extend org.infinispan.interceptors.base.BaseCustomInterceptor instead, and your custom interceptor will have access to a cache and cacheManager. Override stop() and start() for lifecycle methods. > ISPN000173: Custom interceptor org.infinispan.interceptors.CacheMgmtInterceptor has used @Inject, @Start or @Stop. These methods will not be processed. Please extend org.infinispan.interceptors.base.BaseCustomInterceptor instead, and your custom interceptor will have access to a cache and cacheManager. Override stop() and start() for lifecycle methods. > ISPN000173: Custom interceptor org.infinispan.interceptors.DistCacheStoreInterceptor has used @Inject, @Start or @Stop. These methods will not be processed. Please extend org.infinispan.interceptors.base.BaseCustomInterceptor instead, and your custom interceptor will have access to a cache and cacheManager. Override stop() and start() for lifecycle methods. > ISPN000173: Custom interceptor org.infinispan.interceptors.InvalidationInterceptor has used @Inject, @Start or @Stop. These methods will not be processed. Please extend org.infinispan.interceptors.base.BaseCustomInterceptor instead, and your custom interceptor will have access to a cache and cacheManager. Override stop() and start() for lifecycle methods. > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2476) Coordinator thread in AsyncStore could wait forever for worker threads to finish

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2476?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2476: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > Coordinator thread in AsyncStore could wait forever for worker threads to finish > -------------------------------------------------------------------------------- > > Key: ISPN-2476 > URL: https://issues.jboss.org/browse/ISPN-2476 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.0.Beta3 > Reporter: Adrian Nistor > Assignee: Galder Zamarreño > Fix For: 5.2.2, 5.3.0.Final > > > workerThreads.await() should use a timeout. If the wait times out we should log a warning message or something saying that there're some pending modifications. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2013