April 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-905) CacheManager.cacheExists(String cache), CacheManager.getCacheIfExists(String cache), and Cache.exists()

by Patrick McFarland (JIRA)

CacheManager.cacheExists(String cache), CacheManager.getCacheIfExists(String cache), and Cache.exists() ------------------------------------------------------------------------------------------------------- Key: ISPN-905 URL: https://issues.jboss.org/browse/ISPN-905 Project: Infinispan Issue Type: Feature Request Reporter: Patrick McFarland Assignee: Manik Surtani There seems to be no ability to check if a populated cache exists through both CacheManager and through Cache (=is this still a valid handle) and to get a cache if it exists. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

4
23
0 / 0

[JBoss JIRA] Created: (ISPN-960) Non serializable object errors not obvious when repl queue on

by Galder Zamarreño (JIRA)

Non serializable object errors not obvious when repl queue on ------------------------------------------------------------- Key: ISPN-960 URL: https://issues.jboss.org/browse/ISPN-960 Project: Infinispan Issue Type: Bug Components: Marshalling, RPC Affects Versions: 4.2.1.CR3, 4.2.0.Final Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 4.2.1.FINAL Hmmm, it appears that when a cache is configured with REPL_ASYNC and repl queue, a non-serializable object being replicated will fail silently. It would appear as nothing replicates but the error will only become apparent when TRACE is enabled. This is not very nice and would have a direct impact in AS use case, cos web cache is configured this way and users often put stuff in the HTTP session that cannot be replicated. This would cause issues amongst users. Verify what happens with std REPL_ASYNC (I think here the serialization still happens in same thread and so the users would see it). Async marshalling would also need to be checked. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
9
0 / 0

[JBoss JIRA] Created: (ISPN-969) HotRod server not really supporting Berkeley DB as a cache store due to ByteArrayKey not being serializable

by Octavian Florescu (JIRA)

HotRod server not really supporting Berkeley DB as a cache store due to ByteArrayKey not being serializable ----------------------------------------------------------------------------------------------------------- Key: ISPN-969 URL: https://issues.jboss.org/browse/ISPN-969 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 5.0.0.ALPHA3 Reporter: Octavian Florescu Assignee: Manik Surtani Priority: Critical Fix For: 5.0.0.Final Configuring HotRot caches to use BdbjeCacheStore as a cache store does not work: - try to put a value (string) for a key (string) - CacheLoaderInterceptor.loadIfNeeded() is invoked - BdbjeCacheStore.load(Object key) throws as the key is an ByteArrayKey and not serializable -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

4
7
0 / 0

[JBoss JIRA] Created: (ISPN-978) The distribution archives contain a spurious "." directory

by Dan Berindei (JIRA)

The distribution archives contain a spurious "." directory ---------------------------------------------------------- Key: ISPN-978 URL: https://issues.jboss.org/browse/ISPN-978 Project: Infinispan Issue Type: Bug Affects Versions: 5.0.0.ALPHA3, 4.2.1.CR4 Reporter: Dan Berindei Assignee: Manik Surtani In the distribution archives infinispan-version-all.zip and infinispan-version-bin.zip, infinispan-core.jar should be in the directory "infinispan-version". Instead it's in "infinispan-version/.". This causes a problem with some archivers, most notably Windows Explorer, which ignore the contents of the "." directory and only extract the rest of the archive. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
5
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

12 years, 10 months

4
15
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

12 years, 11 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

12 years, 11 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

12 years, 11 months

1
2
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

12 years, 11 months

4
10
0 / 0

[JBoss JIRA] Created: (ISPN-1004) Lifecycle manager for plugin module is invoked twice per cache initialization on cacheStarting

by Sanne Grinovero (JIRA)

Lifecycle manager for plugin module is invoked twice per cache initialization on cacheStarting ---------------------------------------------------------------------------------------------- Key: ISPN-1004 URL: https://issues.jboss.org/browse/ISPN-1004 Project: Infinispan Issue Type: Bug Components: Core API, Querying Reporter: Sanne Grinovero Assignee: Mircea Markus Fix For: 5.0.0.BETA1 In the search module the org.infinispan.query.impl.LifecycleManager is registered via the infinispan-module.properties, but the method {code}org.infinispan.query.impl.LifecycleManager.cacheStarting(ComponentRegistry, Configuration, String){code} Is invoked twice for each cache initialization. The implementation needs to register an interceptor, and some objects in the componentregistry. The tricky part is that some of these components are overwritten, some are not, leading to an inconsistent initialization (Query was made useless). I'm working around this in Query to register my needed components only if they're not already, but this is inconsistent as well as I might need to reconfigure it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

4
11
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2011