February 2013 - infinispan-issues

[JBoss JIRA] (ISPN-2173) NPE when using XA enlistment without recovery

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2173?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2173: -------------------------------- Fix Version/s: (was: 5.2.2.Final) > NPE when using XA enlistment without recovery > --------------------------------------------- > > Key: ISPN-2173 > URL: https://issues.jboss.org/browse/ISPN-2173 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.1.5.FINAL > Reporter: Mircea Markus > Assignee: Mircea Markus > Labels: jdg6 > Fix For: 5.3.0.Final > > > When using xa enlistment (transaction/useSynchronization=false, default), and recovery is disabled (transaction/recovery/enabled=false, default) the transaction manager might invoke recovery related methods such as XAResource.forget() in certain situations. > E.g. the JBossTM invokes "forget", if during, XAResource.commit(xid, true) (second param means 1PC=true) an exception is thrown. (I expect an XAResource.rollback to be invoked in between the failed commit and forget). > Here is such a stack trace: > {quote} > 2012-07-25 14:13:42,821 WARN (testng-CheckRemoteLockAcquiredOnlyOnceDistTest:) [org.infinispan.transaction.xa.TransactionXaAdapter] Exception removing recovery information:java.lang.NullPointerException > at org.infinispan.transaction.xa.TransactionXaAdapter.forget(TransactionXaAdapter.java:159) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.forget(XAResourceRecord.java:759) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:691) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2285) > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1468) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117) > at org.infinispan.lock.CheckRemoteLockAcquiredOnlyOnceTest.testLockThenOperation(CheckRemoteLockAcquiredOnlyOnceTest.java:157) > at org.infinispan.lock.CheckRemoteLockAcquiredOnlyOnceTest.testLockThenPutAll(CheckRemoteLockAcquiredOnlyOnceTest.java:100) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:74) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:673) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) > at org.testng.TestRunner.runWorkers(TestRunner.java:1147) > at org.testng.TestRunner.privateRun(TestRunner.java:749) > at org.testng.TestRunner.run(TestRunner.java:600) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:34) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351) > at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > {quote} > As we do allow xa enlistment *without* recovery enabled this NPE shouldn't be shown to the user. > Instead an warning should be logged stating that XA enlistment is configured without recovery, but recovery might be needed in certain situations. -- 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: (was: 5.2.2.Final) > 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.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-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: (was: 5.2.2.Final) > 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.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-2435) Cache#replace(key, old, new) method doesn't check old value on non-local invocations

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2435?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2435: -------------------------------- Fix Version/s: (was: 5.2.2.Final) > Cache#replace(key, old, new) method doesn't check old value on non-local invocations > ------------------------------------------------------------------------------------ > > Key: ISPN-2435 > URL: https://issues.jboss.org/browse/ISPN-2435 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Cache > Affects Versions: 5.1.8.Final, 5.2.0.Beta2 > Reporter: Sanne Grinovero > Assignee: Mircea Markus > Priority: Critical > Fix For: 5.3.0.Final > > -- 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-2402) Cache operations or transactions should never fail with SuspectException

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2402?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2402: -------------------------------- Fix Version/s: (was: 5.2.2.Final) > Cache operations or transactions should never fail with SuspectException > ------------------------------------------------------------------------ > > Key: ISPN-2402 > URL: https://issues.jboss.org/browse/ISPN-2402 > Project: Infinispan > Issue Type: Task > Components: RPC, State transfer > Affects Versions: 5.2.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 5.3.0.Alpha1 > > Attachments: vrstt.log > > > This is an extension of ISPN-1896 of sorts, but for all the cache operations that are visible to the user. > After a node leaves, the other nodes that have sent commands to that node should either ignore SuspectExceptions or, if not possible, they should retry the operation (e.g. if they didn't get any response back). > For example, VersionReplStateTransferTest quite often on my machine with a SuspectException, because the versioned prepare command expects a response from the coordinator and the coordinator has just left. -- 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-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: (was: 5.2.2.Final) > 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.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-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: (was: 5.2.2.Final) > 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.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-2315) PessimisticDistTxTest.testTxInProgress2 and testTxInProgress1 fail randomly

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2315?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2315: -------------------------------- Fix Version/s: (was: 5.2.2.Final) > PessimisticDistTxTest.testTxInProgress2 and testTxInProgress1 fail randomly > --------------------------------------------------------------------------- > > Key: ISPN-2315 > URL: https://issues.jboss.org/browse/ISPN-2315 > Project: Infinispan > Issue Type: Bug > Reporter: Galder Zamarreño > Assignee: Mircea Markus > Labels: testsuite_stability > Fix For: 5.3.0.Alpha1 > > Attachments: testTxInProgress1-1.log > > > {code}Failed tests: testTxInProgress2(org.infinispan.tx.locking.PessimisticDistTxTest): expected:<false> but was:<true>{code} > Logs: https://dl.dropbox.com/u/6148072/testTxInProgress2-0.tgz -- 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: (was: 5.2.2.Final) > 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.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-2510) PrepareCommands should fail on nodes where the cache is not running

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2510?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2510: -------------------------------- Fix Version/s: (was: 5.2.2.Final) > PrepareCommands should fail on nodes where the cache is not running > ------------------------------------------------------------------- > > Key: ISPN-2510 > URL: https://issues.jboss.org/browse/ISPN-2510 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache, RPC > Affects Versions: 5.2.0.Beta3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 5.3.0.Final > > > When the user stops a cache without stopping the cache manager on that node, subsequent PrepareCommands sent to that node will return a {{SuccessfulResponse}}. > If that node used to the primary owner of the command's modified key, the originator will proceed with the transaction as if it had acquired a lock on that key. It is thus possible for multiple transactions to think they have acquired the key lock at the same time. > On the other hand, in replicated caches is is quite possible that a cache is not running on all the cluster node and yet PrepareCommands are broadcasted to everyone in parallel. So the solution should not involve sending exceptions (which have huge stack traces), and the originator should be able to ignore failures responses from nodes that were not targeted in the first place. -- 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