February 2013 - infinispan-issues

[JBoss JIRA] (ISPN-1822) Cache entry not evicted from memory on IBM JDK when another entry was loaded from a cache loader and maxEntries had been reached

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1822: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > Cache entry not evicted from memory on IBM JDK when another entry was loaded from a cache loader and maxEntries had been reached > -------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-1822 > URL: https://issues.jboss.org/browse/ISPN-1822 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.1.0.FINAL > Environment: java version "1.6.0" > Java(TM) SE Runtime Environment (build pxi3260sr9fp1-20110208_03(SR9 FP1)) > IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260sr9-20110203_74623 (JIT enabled, AOT enabled) ; > java version "1.7.0" > Java(TM) SE Runtime Environment (build pxi3270-20110827_01) > IBM J9 VM (build 2.6, JRE 1.7.0 Linux x86-32 20110810_88604 (JIT enabled, AOT enabled) > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 5.2.2, 5.3.0.Final > > > This behavior is specific to IBM JDK (I tried JDK6 and 7), it works fine with Java HotSpot. > Steps to reproduce the problem: > 1) set maxEntries for eviction to 2 and algorithm e.g. to LRU > 2) store 3 entries key1, key2, key3 to the cache (after that you can see that the cache contains only 2 entries - key2 and key3, the first one was evicted from memory) > 3) call cache.get("key1") > 4) PROBLEM - cache contains all key1, key2, key3 even though it should contain only 2 entries - only happens with IBM JDK (6 or 7 ..no matter) > I'll shortly issue a pull request with a test to ispn-core -- 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-2013) Using explicit "unlock" causes TimeoutException for other Threads

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2013?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2013: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > Using explicit "unlock" causes TimeoutException for other Threads > ----------------------------------------------------------------- > > Key: ISPN-2013 > URL: https://issues.jboss.org/browse/ISPN-2013 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency > Affects Versions: 5.1.2.FINAL > Environment: Windows 7 64-bit > Reporter: Dmitry Udalov > Assignee: Mircea Markus > Fix For: 5.2.2, 5.3.0.Final > > Attachments: LockTest.java > > > In a test I have several tasks that run on a single cache node configured as transactional pessimistic replicated cache. If I explicitly call "unlock" then I consistently see TimeoutException reported by some tasks. Without explicit "unlock" the test works fine. Does it mean that I should never call "unlock" and rely on transaction.commit/rollback ? It's seen with infinispan-5.1.2.FINAL > > Here's what in a nutshell each task does: > > final lockKey = ... > > executor.submit(new Callable<Boolean>() { > public Boolean call() throws Exception > > TransactionManager tx = cache.getAdvancedCache().getTransactionManager(); > tx.begin() > try { > if ( lockManager.lock(lockKey) ) { > > // ... > > // removing next line makes test happy. Otherwise some tasks report TimeoutException (pls. see the stack traces) > cache.getLockManager().unlock(lockKey); > } > } catch(Throwable t) { > tx.setRollbackOnly(); > } finally { > if (ut.getStatus() == Status.STATUS_ACTIVE) > ut.commit(); > else > ut.rollback(); > } > > > By the time I received that exception all other tasks were completed and they released the lock on the key in question. > I also see that LockManagerImpl.lock recognized that the lock was not owned by any thread - see "Lock held by [null]", which seems to be right. But yet the lock failed to be acquired. > Is it a matter to trying it one more time? > > org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [10 seconds] on key [foo] for requestor [GlobalTransaction:<Sound-15075>:8:local]! Lock held by [null] > at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:206) > at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:180) > at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:170) > at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:209) > at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAndRegisterBackupLock(AbstractTxLockingInterceptor.java:136) > at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:228) > at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) > at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:159) > at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) > at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:144) > at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) > at org.infinispan.interceptors.StateTransferLockInterceptor.handleWithRetries(StateTransferLockInterceptor.java:207) > at org.infinispan.interceptors.StateTransferLockInterceptor.visitLockControlCommand(StateTransferLockInterceptor.java:138) > at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) > at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:159) > at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:130) > at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:94) > at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345) > at org.infinispan.CacheImpl.lock(CacheImpl.java:484) > at org.infinispan.CacheImpl.lock(CacheImpl.java:468) -- 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-2162) ParallelCacheStartTest.testParallelStartup fails randomly

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2162?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2162: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > ParallelCacheStartTest.testParallelStartup fails randomly > --------------------------------------------------------- > > Key: ISPN-2162 > URL: https://issues.jboss.org/browse/ISPN-2162 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Galder Zamarreño > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 5.2.2, 5.3.0.Alpha1 > > > Failed tests: testParallelStartup(org.infinispan.api.ParallelCacheStartTest): Timed out before caches had complete views. Expected 1 members in each view. Views are as follows: [[ParallelCacheStartTest-NodeA-41416, ParallelCacheStartTest-NodeB-21482]] -- 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-2050) Query is attempting to run a KeyTransformer on types which are not meant to be indexed

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2050?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2050: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > Query is attempting to run a KeyTransformer on types which are not meant to be indexed > -------------------------------------------------------------------------------------- > > Key: ISPN-2050 > URL: https://issues.jboss.org/browse/ISPN-2050 > Project: Infinispan > Issue Type: Bug > Components: Querying > Affects Versions: 5.1.3.FINAL > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 5.2.2, 5.3.0.Alpha1 > > -- 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-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: 5.2.2 (was: 5.2.1) > 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.2.2, 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-2160) ReplWriteSkewTest.testSharedCounter failing randomly

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2160?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2160: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > ReplWriteSkewTest.testSharedCounter failing randomly > ---------------------------------------------------- > > Key: ISPN-2160 > URL: https://issues.jboss.org/browse/ISPN-2160 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Galder Zamarreño > Assignee: Adrian Nistor > Labels: testsuite_stability > Fix For: 5.2.2, 5.3.0.Alpha1 > > > Failing randomly with: > {code}Failed tests: > testSharedCounter(org.infinispan.container.versioning.ReplWriteSkewTest): > Node-2 has put a duplicate value{code} > TRACE logs coming right up -- 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-2161) InitiatorCrashPessimisticReplTest.testInitiatorNodeCrashesBeforeCommit fails randomly

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2161?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2161: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > InitiatorCrashPessimisticReplTest.testInitiatorNodeCrashesBeforeCommit fails randomly > ------------------------------------------------------------------------------------- > > Key: ISPN-2161 > URL: https://issues.jboss.org/browse/ISPN-2161 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Galder Zamarreño > Assignee: Mircea Markus > Labels: testsuite_stability > Fix For: 5.2.2, 5.3.0.Alpha1 > > Attachments: testInitiatorNodeCrashesBeforeCommit-0.log > > > Failed tests: testInitiatorNodeCrashesBeforeCommit(org.infinispan.lock.singlelock.replicated.pessimistic.InitiatorCrashPessimisticReplTest): expected key 'k' to be locked on cache Cache '___defaultcache'@InitiatorCrashPessimisticReplTest-NodeD-44283, but it is not -- 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-2103) Concurrent access after removal of an AtomicMap should NOT result in an IllegalStateException when accessed by other threads

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2103?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2103: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > Concurrent access after removal of an AtomicMap should NOT result in an IllegalStateException when accessed by other threads > ---------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2103 > URL: https://issues.jboss.org/browse/ISPN-2103 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.1.5.FINAL > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.2.2, 5.3.0.Final > > > ISPN-1121 introduces an IllegalStateException that is being thrown from AtomicMap methods once the map handle has become stale (ie. removed from cache). In case of concurrent access, the exception is thrown to all threads not just to the thread that performed the removal. This was fine-ish in older versions of Infinispan before introduction of optimistic and pessimistic locking but it should be reconsidered now because: > 1. It interferes/overlaps with transaction isolation. We should rely on the selected locking scheme (OL/PL) to detect conflicts between transactions and report the problem accordingly. Especially if the stale map is used just for reading - this should be allowed to work rather than stop it. > 2. This exception is pretty disruptive and awkward to handle. All methods of an AtomicMap can result in this exception and the current thread has to be prepared for handling it if other threads remove the map. Not much transaction isolation. > 3. Since the TreeCache is backed by AtomicMap nearly all Tree API can throw this. > The proposed fix consists of: > 1. removing AtomicHashMap.removed flag and AtomicHashMap.markRemoved() method. > 2. revising AtomicHashMapProxy.assertValid() method to check only if the map is null (ie. removed) but no longer use the removed flag. > 3. revising ReadCommittedEntry.commit() method to no longer call markRemoved() method. > The consequences of these changes are: > 1. Any further access to a stale map results in IllegalStateException ONLY in the thread that performed the removal. This thread 'knows' the map is stale so it is fine to punish it. Other threads remain unaffected until lock acquisition or commit is performed (depending on locking model). > 2. Other threads can continue to use the previously obtained map handle for reads without danger of getting an exception. > 3. If a write operation is done on the map, the results depend on the locking model: > 3.1 optimistic locking + write skew check: a WriteSkewException will stop the commit during prepare > 3.2 optimistic locking, no write skew check: the write is committed and the work of the transaction that removed the map is overwritten. The map is effectively revived. > 3.3 pessimistic locking: same as 3.2 > Please note 3.2 and 3.3 work the same as for normal values (not atomic maps). -- 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-2059) Custom CacheLoaders are treated as CacheStores unless annotated with @CacheLoaderMetadata

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2059?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2059: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > Custom CacheLoaders are treated as CacheStores unless annotated with @CacheLoaderMetadata > ----------------------------------------------------------------------------------------- > > Key: ISPN-2059 > URL: https://issues.jboss.org/browse/ISPN-2059 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.1.6.FINAL > Reporter: Sanne Grinovero > Assignee: Tristan Tarrant > Fix For: 5.2.2, 5.3.0.Final > > > If the @CacheLoaderMetadata is missing, Infinispan will treat the CacheLoader as a CacheStore: if it's not implementing CacheStore as well the component will fail. > @CacheLoaderMetadata should be optional. -- 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: 5.2.2 (was: 5.2.1) > 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.2.2, 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2013