September 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 Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-1822: -------------------------------------- Fix Version/s: 6.0.0.CR1 (was: 6.0.0.Beta2) > 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: Tristan Tarrant > Fix For: 6.0.0.CR1 > > > 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3318) Migrate data from one cache store to another

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-3318?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-3318: -------------------------------------- Fix Version/s: 6.0.0.CR1 (was: 6.0.0.Beta2) > Migrate data from one cache store to another > -------------------------------------------- > > Key: ISPN-3318 > URL: https://issues.jboss.org/browse/ISPN-3318 > Project: Infinispan > Issue Type: Task > Components: Loaders and Stores > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 6.0.0.CR1, 6.0.0.Final > > > Find a generic way to transfer data from one cache store to another, which could involve different Infinispan versions. This is handy to migrate file cache store based users to single file cache store (ISPN-2806). > Ideally, this should be added as a recipe for rolling upgrades. -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3285) Remove dependency to Lucene Analyzers

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-3285?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-3285: -------------------------------------- Fix Version/s: (was: 6.0.0.Beta2) > Remove dependency to Lucene Analyzers > ------------------------------------- > > Key: ISPN-3285 > URL: https://issues.jboss.org/browse/ISPN-3285 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Reporter: Sanne Grinovero > Assignee: Adrian Nistor > Fix For: 6.0.0.CR1 > > > Or at least make it optional/test -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2727) Transactional put failed after master node with enabled InfinispanIndexManager is killed

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-2727?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-2727: -------------------------------------- Fix Version/s: (was: 6.0.0.Beta2) > Transactional put failed after master node with enabled InfinispanIndexManager is killed > ----------------------------------------------------------------------------------------- > > Key: ISPN-2727 > URL: https://issues.jboss.org/browse/ISPN-2727 > Project: Infinispan > Issue Type: Bug > Components: Querying > Reporter: Anna Manukyan > Assignee: Adrian Nistor > Fix For: 6.0.0.CR1 > > Attachments: MultiNodeDistributedTest.java, MultiNodeLocalTest.java, MultiNodeLocalTxTest.java, MultiNodeReplicatedTest.java, MultiNodeReplicatedTxTest.java > > > I've added new test, which uses the following Infinispan configuration: REPL_SYNC clustering mode, with transaction enabled, as well as enabled indexing with InfinispanIndexManager. > The test adds several nodes with the described configuration, adds entries to different nodes, and checks that the query for the entries returns the same result for all nodes. > Then master node is killed, and then again new data is inserted and checked on all nodes. (Similiar test to https://github.com/infinispan/infinispan/blob/master/query/src/test/java/... but with enabled transaction). > When the test tries to insert new entry to one of the caches, after the master node kill, the following exception appears: > {code} > testIndexingWorkDistribution(org.infinispan.query.distributed.MultiNodeReplicatedTxTest) Time elapsed: 1.656 sec <<< FAILURE! > javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction. > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1177) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117) > at org.infinispan.query.distributed.MultiNodeDistributedTest.storeOn(MultiNodeDistributedTest.java:78) > at org.infinispan.query.distributed.MultiNodeDistributedTest.testIndexingWorkDistribution(MultiNodeDistributedTest.java:102) > 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:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:715) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > 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) > Caused by: org.infinispan.CacheException: Could not prepare. > at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:70) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) > ... 24 more > Caused by: javax.transaction.xa.XAException > at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:161) > at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:123) > at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68) > ... 29 more > {code} > You can find the test attached. The test which fails is MultiNodeReplicatedTxTest.java . The rest are the tests which are the parents and a bit modified compared to the version in infinispan repo. -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3556) When LockControlCommand fails on an owner, the rollback command is not sent

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-3556?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-3556: -------------------------------------- Fix Version/s: 6.0.0.CR1 (was: 6.0.0.Beta2) > When LockControlCommand fails on an owner, the rollback command is not sent > --------------------------------------------------------------------------- > > Key: ISPN-3556 > URL: https://issues.jboss.org/browse/ISPN-3556 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency > Affects Versions: 5.2.7.Final, 5.3.0.Final, 6.0.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 6.0.0.CR1 > > > If a transaction starts with a {{lock()}} operation and the lock fails on one of the owners (e.g. because of a {{SuspectException}}), the rollback command should still be sent to all the live owners. > However, because a locked key is only registered in the {{affectedKeys}} collection after a successful lock operation (in {{PessimisticLockingInterceptor.acquireRemoteIfNeeded()}}, the rollback command is not sent to any owners. > This is in a pessimistic cache. However, looking at the {{OptimisticLockingInterceptor.acquireAllLocks()}} code I think I see a similar problem: it's possible that a key is locked, but the write skew check fails and the key is not added to the {{affectedKeys}} collection. We should always register the key first and attempt to lock it after. -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3513) LevelDBStore.init called three times

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-3513?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-3513: -------------------------------------- Fix Version/s: 6.0.0.CR1 (was: 6.0.0.Beta2) > LevelDBStore.init called three times > ------------------------------------ > > Key: ISPN-3513 > URL: https://issues.jboss.org/browse/ISPN-3513 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha4 > Reporter: Michal Linhard > Assignee: Mircea Markus > Fix For: 6.0.0.CR1 > > > PersistenceManagerImpl.createLoadersAndWriters > calls LevelDBStore.init three times unnecessarily. > Also note that LevelDBStore is both CacheWriter and CacheLoader and the logic of createLoadersAndWriters doesn't seem to take into account that these are not exclusive. -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3460) Refactor the CacheEntry hierarchy

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-3460?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-3460: -------------------------------------- Fix Version/s: 6.0.0.CR1 (was: 6.0.0.Beta2) > Refactor the CacheEntry hierarchy > --------------------------------- > > Key: ISPN-3460 > URL: https://issues.jboss.org/browse/ISPN-3460 > Project: Infinispan > Issue Type: Enhancement > Reporter: Mircea Markus > Assignee: William Burns > Fix For: 6.0.0.CR1 > > > ATM we keep the metadata information in 3 places: CacheValues, CacheEntries and Metadata. We should move everything in the Metadata and make the CacheValues and the CacheEntries reference it. > Also look at MimeMetadataHelper in REST cache store... -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3443) WriteCommand may be ignored during state transfer

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-3443?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-3443: -------------------------------------- Fix Version/s: 6.0.0.CR1 (was: 6.0.0.Beta2) > WriteCommand may be ignored during state transfer > ------------------------------------------------- > > Key: ISPN-3443 > URL: https://issues.jboss.org/browse/ISPN-3443 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency, State transfer > Affects Versions: 6.0.0.Alpha3 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.CR1 > > > Distributed sync non-tx cache. > Situation: > 1) A node is joining the cluster, requesting some segment > 2) RemoveCommand is sent to backup owner with ignorePreviousValue=true > 3) It looks up the entry and finds null > 4) State transfer invokes the PutKeyValueCommand and sets the value for removed entry (updateKeys has not the key yet) > 5) RemoveCommand adds its key to updateKeys set, but it does not remove the value as it is already null (in its context) > Result: the value is removed on primary but on backup this is still present -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3490) extend compatibility mode tests

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3490?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-3490: ------------------------------------- [~mgencur] Was just looking at CompatModeQueryDslConditionsTest, it does indeed activate compatibility mode (which just adds TypeConverterInterceptor to the stack) but nothing special happens unless the commands come from a remote client. See usage of flag Flag.OPERATION_HOTROD and Flag.OPERATION_MEMCACHED in method TypeConverterInterceptor.determineTypeConverter. This test should should use the Hot Rod client and should probably placed in the infinispan-compatibility-mode-it module. > extend compatibility mode tests > ------------------------------- > > Key: ISPN-3490 > URL: https://issues.jboss.org/browse/ISPN-3490 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Martin Gencur > Fix For: 6.0.0.CR1, 6.0.0.Final > > > - to cover map/reduce > - to cover embedded queries > - to cover listeners > - transaction > -.. pretty much all the existing functionality -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3558) PutForExternalRead won't work after a clear(), when both in same tx

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3558?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-3558: ----------------------------------- Assignee: William Burns (was: Mircea Markus) > PutForExternalRead won't work after a clear(), when both in same tx > ------------------------------------------------------------------- > > Key: ISPN-3558 > URL: https://issues.jboss.org/browse/ISPN-3558 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.3.0.Final, 6.0.0.Beta1 > Reporter: Galder Zamarreño > Assignee: William Burns > Fix For: 6.0.0.CR1, 6.0.0.Final > > > {code} > public void testPutForExternalReadAfterClear() throws Exception { > cache.put(1, "v1"); > tm().begin(); > try { > cache.getAdvancedCache().clear(); > cache.putForExternalRead(1, "v1"); > assertEquals("v1", cache.get(1)); > } finally { > tm().commit(); > } > } > {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

11 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2013