June 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-1166) Eviction might release locks it didn't acquire

by Sanne Grinovero (JIRA)

Eviction might release locks it didn't acquire ---------------------------------------------- Key: ISPN-1166 URL: https://issues.jboss.org/browse/ISPN-1166 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.0.0.CR4 Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Critical Fix For: 5.0.0.CR5 EvictionManagerImpl doesn't check if it actually had acquired a lock before releasing it. It also might fail to release them if the eviction listeners throw an exception. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-993) Help to prevent deadlocks by making the lock id accessible through the public API

by Nicolas Filotto (JIRA)

Help to prevent deadlocks by making the lock id accessible through the public API --------------------------------------------------------------------------------- Key: ISPN-993 URL: https://issues.jboss.org/browse/ISPN-993 Project: Infinispan Issue Type: Feature Request Reporter: Nicolas Filotto Assignee: Manik Surtani To prevent deadlocks when we use ISPN with transactions, we need to sort the keys before calling a method that acquires a lock such as cache.put and cache.remove. For example when we don't use the lock striping (i.e. we use one lock per key), the following use case will create a deadlock: Thread #1 does: {code} tm.begin() // We acquire the lock on "A" cache.put("A","A"); // We acquire the lock on "B" cache.put("B","B"); // Here all the acquired locks will be released tm.commit(); {code} Thread #2 does: {code} tm.begin() // We acquire the lock on "B" cache.put("B","B"); // We acquire the lock on "A" cache.put("A","A"); // Here all the acquired locks will be released tm.commit(); {code} To prevent this deadlock we can simply sort the keys within the Tx such that the lock acquisition is done in the same order. Unfortunately when we use lock striping even when we sort the keys we can face deadlocks because we cannot predict how the locks are distributed over the keys. For example the following test case creates a deadlock when the lock striping is enabled. {code} public class TestDeadlock extends TestCase { /** * We get an unpredictable deadlock because apart if we know the implementation * of the ReentrantStripedLockContainer, we cannot know that the keys * 8 * "a" and 13 * "a" are mapped to the same lock and 11 * "a" and 14 * "a" are * both mapped to the same lock that is different from the first one. * In the use case below the keys are sorted but we still get a deadlock */ public void testUseLockStripingTrueUnpredictableDeadLock() throws Exception { DefaultCacheManager manager = new DefaultCacheManager(); manager.getDefaultConfiguration().setInvocationBatchingEnabled(true); manager.getDefaultConfiguration().setLockAcquisitionTimeout(1000); final Cache<String, String> cache = manager.getCache(); final CountDownLatch startSignal = new CountDownLatch(1); final CountDownLatch endSignal = new CountDownLatch(2); final AtomicReference<Exception> exception = new AtomicReference<Exception>(); new Thread() { /** * @see java.lang.Thread#run() */ @Override public void run() { try { cache.startBatch(); startSignal.await(); // 8 * "a" cache.put("aaaaaaaa", "Value"); // 14 * "a" cache.put("aaaaaaaaaaaaaa", "Value"); cache.endBatch(true); } catch (Exception e) { exception.set(e); } finally { endSignal.countDown(); } } }.start(); new Thread() { /** * @see java.lang.Thread#run() */ @Override public void run() { try { cache.startBatch(); startSignal.await(); // 11 * "a" cache.put("aaaaaaaaaaa", "Value2"); // 13 * "a" cache.put("aaaaaaaaaaaaa", "Value2"); cache.endBatch(true); } catch (Exception e) { exception.set(e); } finally { endSignal.countDown(); } } }.start(); startSignal.countDown(); endSignal.await(); assertNull(exception.get()); } } {code} If we could get the lock id thanks to the public API, we could sort our keys according to this value and then avoid the deadlocks even when the lock striping is enabled. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

4
15
0 / 0

[JBoss JIRA] Created: (ISPN-1170) Rehashing doesn't rebalance keys for which the old owners and the new owners are disjoint sets

by Dan Berindei (JIRA)

Rehashing doesn't rebalance keys for which the old owners and the new owners are disjoint sets ---------------------------------------------------------------------------------------------- Key: ISPN-1170 URL: https://issues.jboss.org/browse/ISPN-1170 Project: Infinispan Issue Type: Bug Affects Versions: 5.0.0.CR4 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.0.0.CR5 The node that does the push is computed as the last owner in the old CH that is still an owner in the new CH. Instead it should be the last owner in the old CH that is still alive in the new CH. With the default CH this can never happen, but with the topology-aware CH it could, e.g.: old CH = {A{mid=m0}, B{mid=m1}, C{mid=m1}, D{mid=m2}} old owners(k) = {B, D} new CH = {A{mid=m0}, C{mid=m1}, D{mid=m2}} new owners(k) = {A, C} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (ISPN-1059) Document using Infinispan with Spring on http://community.jboss.org/wiki/Infinispan

by Manik Surtani (JIRA)

Document using Infinispan with Spring on http://community.jboss.org/wiki/Infinispan ----------------------------------------------------------------------------------- Key: ISPN-1059 URL: https://issues.jboss.org/browse/ISPN-1059 Project: Infinispan Issue Type: Sub-task Reporter: Manik Surtani Assignee: Olaf Bergner Fix For: 4.2.2.BETA1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

4
11
0 / 0

[JBoss JIRA] Created: (ISPN-663) Eviction with passivation using JdbmCacheStore is 100 times slower in 4.1 vs 4.0

by Paul Nardone (JIRA)

Eviction with passivation using JdbmCacheStore is 100 times slower in 4.1 vs 4.0 -------------------------------------------------------------------------------- Key: ISPN-663 URL: https://jira.jboss.org/browse/ISPN-663 Project: Infinispan Issue Type: Bug Components: Eviction, Loaders and Stores Affects Versions: 4.1.0.Final Environment: Win32 JRE 1.6.0_21 Reporter: Paul Nardone Assignee: Manik Surtani Attachments: InfinispanPassivationTest.java Eviction with passivation enabled using the JdbmCacheStore appears to be significantly slower in 4.1.0.FINAL vs 4.0.0.FINAL. The degredation in performance is so signficant to make it impossible to use The performance issue seems to due as the JdbmCacheStore synching the filesystem via FileDescriptor.sync() or similar which occurs during every object passivation and each passivation occurs as a new object is added beyond the EvictionMaxEntries capacity. The attached test inserts 1000 values into two caches Both caches use a JdbmCacheStore and LRU PASSIVATIONLRU10 runs with cache with EvictionMaxEntries 10 PASSIVATIONLRU1000 runs with cache with EvictionMaxEntries 1000 4.1.0.FINAL PASSIVATIONLRU10 Time Taken : 51704 PASSIVATIONLRU1000 Time Taken : 4484 4.0.0.FINAL PASSIVATIONLRU10 Time Taken : 281 PASSIVATIONLRU1000 Time Taken : 141 4.2.0.ALPHA2 PASSIVATIONLRU10 Time Taken : 51047 PASSIVATIONLRU1000 Time Taken : 5156 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

5
36
0 / 0

[JBoss JIRA] Created: (ISPN-869) Enable automatic keyspace creation with cassandra 0.7

by Tristan Tarrant (JIRA)

Enable automatic keyspace creation with cassandra 0.7 ------------------------------------------------------ Key: ISPN-869 URL: https://issues.jboss.org/browse/ISPN-869 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Reporter: Tristan Tarrant Assignee: Tristan Tarrant Priority: Minor Fix For: 5.0.0.Final Cassandra 0.7 allows creation of keyspaces and columnfamilies at runtime. We should add a boolean flag (false by default) to automatically create the Infinispan keyspaces and columnfamilies. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-1144) Replicated caches should have state transfer enabled by default

by Galder Zamarreño (JIRA)

Replicated caches should have state transfer enabled by default --------------------------------------------------------------- Key: ISPN-1144 URL: https://issues.jboss.org/browse/ISPN-1144 Project: Infinispan Issue Type: Enhancement Components: State transfer Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.FINAL +1 on enabling state transfer for replicated caches; without ST replicated caches don't make much sense. --- On 5/27/11 5:32 PM, Galder Zamarreño wrote: Hey, Re: http://community.jboss.org/message/607524#607524 This guy didn't have state transfer enabled which is the cause for his initial issues. It's clear that http://community.jboss.org/docs/DOC-13690 needs to have state transfer in its config, otherwise replication does not make much sense... I'm doing this just now The other more key thing is probably making state transfer enabled by default for replicated caches. I previously looked into it but did not look straight forward to do as my comment here says: https://github.com/galderz/infinispan/blob/master/core/src/main/java/org/... However, I think it might be worth looking into it again. Thoughts? -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache -- Bela Ban Lead JGroups / Clustering Team JBoss -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
5
0 / 0

[JBoss JIRA] Created: (ISPN-721) Change CacheStore.store() to return the previous value instead of void.

by Trustin Lee (JIRA)

Change CacheStore.store() to return the previous value instead of void. ----------------------------------------------------------------------- Key: ISPN-721 URL: https://jira.jboss.org/browse/ISPN-721 Project: Infinispan Issue Type: Task Components: Core API Affects Versions: 4.2.0.Final Reporter: Trustin Lee Assignee: Trustin Lee Fix For: 5.0.0.BETA1 Cache.put(key, value) operation returns a previous value. However, CacheStore.store() does not return a previous value but void. To overcome the impedance mismatch, the current implementation calls CacheStore.load() to simply get the previous value. CacheStore.store() could be improved to reduce this unnecessary round trip. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

4
10
0 / 0

[JBoss JIRA] Created: (ISPN-1159) Cassandra Cache Store tests are failing

by Tristan Tarrant (JIRA)

Cassandra Cache Store tests are failing --------------------------------------- Key: ISPN-1159 URL: https://issues.jboss.org/browse/ISPN-1159 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 5.0.0.CR4 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 5.0.0.CR5 The cassandra cache store tests fail because cassandra chooses an "alternative" localhost address. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (ISPN-1140) TransientMortalCacheEntry has incorrect implementation of setValue()

by Steven Newson (JIRA)

TransientMortalCacheEntry has incorrect implementation of setValue() -------------------------------------------------------------------- Key: ISPN-1140 URL: https://issues.jboss.org/browse/ISPN-1140 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.0.0.CR3, 4.2.1.FINAL Reporter: Steven Newson Assignee: Manik Surtani The implementation of {{setValue()}} in {{TransientMortalCacheEntry}} is as follows {code:java} public Object setValue(Object value) { return cacheValue.maxIdle; } {code} This leads to problems in the {{DefaultDataContainer}} as the following {{put()}} code has no effect: {code:java} public void put(Object k, Object v, long lifespan, long maxIdle) { InternalCacheEntry e = entries.get(k); if (e != null) { e.setValue(v); InternalCacheEntry original = e; e = entryFactory.update(e, lifespan, maxIdle); // we have the same instance. So we need to reincarnate. if(original == e) { e.reincarnate(); } } else { // this is a brand-new entry e = entryFactory.createNewEntry(k, v, lifespan, maxIdle); } entries.put(k, e); } {code} The effect of this for me is that the following steps via Hibernate don't work: - Insert record into table via Hibernate - Reload record by its ID - Change non-ID field on the record - Update the record via Hibernate - Reload the record by its ID - Check that the value reloaded matches the updated value The 2nd level cache always returns the first inserted record rather than the updated one. Each Hibernate access is inside its own transaction. I fixed this locally by overriding the class in the classpath, replacing the {{setValue()}} method with the following implementation: {code:java} public Object setValue(Object value) { Object original = cacheValue.value; cacheValue.value = value; return original; } {code} Which also corresponds to the (misspelled :)) Javadoc: {noformat}Sets the value of the entry, returing the previous value{noformat} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

4
14
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2011