May 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-961) Implement a provider for Spring's Cache Abstraction

by Sanne Grinovero (JIRA)

Implement a provider for Spring's Cache Abstraction --------------------------------------------------- Key: ISPN-961 URL: https://issues.jboss.org/browse/ISPN-961 Project: Infinispan Issue Type: Feature Request Reporter: Sanne Grinovero Assignee: Manik Surtani As described on http://blog.springsource.com/2011/02/23/spring-3-1-m1-caching/ , Spring is now providing some integration helpers to a caching interface; it seems easy to implement. there are many possible issues using this the wrong way, we should especially warn about not caching JPA entities this way. See topic "Spring Cache Abstraction " here: http://lists.jboss.org/pipermail/hibernate-dev/2011-February/thread.html#... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

5
14
0 / 0

[JBoss JIRA] Created: (ISPN-1092) TopologyAwareConsistentHash with virtual nodes enabled can return two owners for a key when there is only one node in the cluster

by Dan Berindei (JIRA)

TopologyAwareConsistentHash with virtual nodes enabled can return two owners for a key when there is only one node in the cluster --------------------------------------------------------------------------------------------------------------------------------- Key: ISPN-1092 URL: https://issues.jboss.org/browse/ISPN-1092 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.0.0.CR1 Reporter: Dan Berindei Assignee: Pete Muir Priority: Minor See org.infinispan.distribution.vnodes.VNodesCHPerfTest.testSpeed(), it fails when numNodes == 1 and numOwners == 2. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
4
0 / 0

[JBoss JIRA] Created: (ISPN-720) Replace CacheEntryEvictedEvent with CacheEntriesEvictedEvent (note the plural)

by Trustin Lee (JIRA)

Replace CacheEntryEvictedEvent with CacheEntriesEvictedEvent (note the plural) ------------------------------------------------------------------------------ Key: ISPN-720 URL: https://jira.jboss.org/browse/ISPN-720 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 CacheEntryEvictedEvent should be replaced with CacheEntriesEvictedEvent to fully utilize the improvements in EvictionListener (see ISPN-718). -- 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
18
0 / 0

[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, 11 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, 11 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, 11 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, 11 months

3
5
0 / 0

[JBoss JIRA] Created: (ISPN-1112) Log cache name in named components

by Galder Zamarreño (JIRA)

Log cache name in named components ---------------------------------- Key: ISPN-1112 URL: https://issues.jboss.org/browse/ISPN-1112 Project: Infinispan Issue Type: Enhancement Reporter: Galder Zamarreño Assignee: Manik Surtani Fix For: 5.0.0.CR3 Use NDC or MDC in JBoss Logging in order to log cache name when named cache components log something. More info on the dev list discussion. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

3
6
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, 11 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2011