September 2012 - infinispan-issues

[JBoss JIRA] (ISPN-2240) Per-key lock container leads to superfluous TimeoutExceptions on concurrent access to same key

by Robert Stupp (JIRA)

Robert Stupp created ISPN-2240: ---------------------------------- Summary: Per-key lock container leads to superfluous TimeoutExceptions on concurrent access to same key Key: ISPN-2240 URL: https://issues.jboss.org/browse/ISPN-2240 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Affects Versions: 5.1.6.FINAL Reporter: Robert Stupp Assignee: Mircea Markus Attachments: somehow.zip Hi, I've encountered a lot of TimeoutExceptions just running a load test against an infinispan cluster. I tracked down the reason and found out, that the code in org.infinispan.util.concurrent.locks.containers.AbstractPerEntryLockContainer#releaseLock() causes these superfluous TimeoutExceptions. A small test case (which just prints out timeouts, too late timeouts and "paints" a lot of dots to the console - more dots/second on the console means better throughput ;-) In a short test I extended the class ReentrantPerEntryLockContainer and changed the implementation of releaseLock() as follows: {noformat} public void releaseLock(Object lockOwner, Object key) { ReentrantLock l = locks.get(key); if (l != null) { if (!l.isHeldByCurrentThread()) throw new IllegalStateException("Lock for [" + key + "] not held by current thread " + Thread.currentThread()); while (l.isHeldByCurrentThread()) unlock(l, lockOwner); if (!l.hasQueuedThreads()) locks.remove(key); } else throw new IllegalStateException("No lock for [" + key + ']'); } {noformat} The main improvement is that locks are not removed from the concurrent map as long as other threads are waiting on that lock. If the lock is removed from the map while other threads are waiting for it, they may run into timeouts and force TimeoutExceptions to the client. The above methods "paints more dots per second" - means: it gives a better throughput for concurrent accesses to the same key. The re-implemented method should also fix some replication timeout exceptions. Please, please add this to 5.1.7, if possible. -- 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

12 years, 3 months

5
17
0 / 0

[JBoss JIRA] (ISPN-2205) Design HotRod protocol version 1.2

by Dan Berindei (JIRA)

Dan Berindei created ISPN-2205: ---------------------------------- Summary: Design HotRod protocol version 1.2 Key: ISPN-2205 URL: https://issues.jboss.org/browse/ISPN-2205 Project: Infinispan Issue Type: Task Components: Cache Server Affects Versions: 5.2.0.ALPHA2 Reporter: Dan Berindei Assignee: Dan Berindei Priority: Critical Fix For: 5.2.0.FINAL The consistent hash representation is changing in 5.2, and we need to modify the HotRod protocol to incorporate those changes. We preserved compatibility with 1.0/1.1 clients with a workaround on the server, but is not as efficient as it could be. The new version could also incorporate fixes for older issues like ISPN-1293. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

4
13
0 / 0

[JBoss JIRA] (ISPN-2192) Allow using Distributed Execution against any cache (not just clustered caches)

by Randall Hauch (JIRA)

Randall Hauch created ISPN-2192: ----------------------------------- Summary: Allow using Distributed Execution against any cache (not just clustered caches) Key: ISPN-2192 URL: https://issues.jboss.org/browse/ISPN-2192 Project: Infinispan Issue Type: Enhancement Affects Versions: 5.1.2.FINAL Reporter: Randall Hauch Assignee: Manik Surtani Priority: Critical It is often desirable to process all entries in a cache, and there is no reliable and consistent way to do that for any cache. If a cache is clustered, then map-reduce can be used (although IIUC it currently doesn't guarantee to process non-materialized entries for caches that have a cache store) and distributed execution can be used (IIUC this will be called for all keys owned by the cluster node). However, neither of these work on local caches. If a cache is local and there is no cache store, then apparently {{keySet()}} does work and allows a client to iterate over the keys in the local cache. However, if the local cache is configured to have a cache store, then the {{keySet()}} method will return only the keys for the materialized entries and does not return all of the keys in the cache. Of course, if a local cache does have a cache store, then its possible to obtain the keys using {{CacheLoader.loadAllKeys(...)}} (obviously this is probably not something a client should do). In short, it should be possible to use Distributed Execution against any cache, regardless of its configuration. (Ideally, it would be possible for Map-Reduce to also be used against any cache.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

5
13
0 / 0

[JBoss JIRA] (ISPN-2106) StateTransferFunctionalTest.testSTWithThirdWritingNonTxCache failing randomly

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2106: -------------------------------------- Summary: StateTransferFunctionalTest.testSTWithThirdWritingNonTxCache failing randomly Key: ISPN-2106 URL: https://issues.jboss.org/browse/ISPN-2106 Project: Infinispan Issue Type: Bug Components: State transfer, Test Suite Reporter: Galder Zamarreño Assignee: Dan Berindei Fix For: 5.2.0.ALPHA1 See: https://infinispan.ci.cloudbees.com/job/Infinispan-master-JDK6-tcp/org.in... and https://infinispan.ci.cloudbees.com/job/Infinispan-5.1.x-JDK6-tcp/org.inf... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

5
14
0 / 0

[JBoss JIRA] (ISPN-2323) RemoteCacheStore should optionally put/get raw values (instead of InternalCacheEntries)

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2323: ------------------------------------- Summary: RemoteCacheStore should optionally put/get raw values (instead of InternalCacheEntries) Key: ISPN-2323 URL: https://issues.jboss.org/browse/ISPN-2323 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 5.2.0.Final Accessing a remote HotRod cache via a RemoteCacheManager and a RemoteCacheStore is not possible since the former stores plain values whereas the latter stores InternalCacheEntries. We should enhance the RemoteCacheStore to be able to "unwrap/wrap" cache entries -- 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

12 years, 3 months

3
9
0 / 0

[JBoss JIRA] Created: (ISPN-1293) Enable default lifespan/maxIdle values to be used by the Hot Rod server

by Galder Zamarreño (JIRA)

Enable default lifespan/maxIdle values to be used by the Hot Rod server ----------------------------------------------------------------------- Key: ISPN-1293 URL: https://issues.jboss.org/browse/ISPN-1293 Project: Infinispan Issue Type: Enhancement Components: Cache Server Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.2.0.FINAL Hot Rod clients should be able to tell the server that no lifespan/maxIdle value was given, and so that the server should use the default lifespan+maxIdle values set in configuration. This is not currently possible in v1 of the protocol and so requires a change of protocol. This is the result of the investigation for ISPN-1285, and so when this is resolved: 1. Make sure you revert the javadoc added to ISPN-1285 to document the limitation 2. Enable and expand client/hotrod-client/src/test/java/org/infinispan/client/hotrod/ExpiryTest.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

4
9
0 / 0

[JBoss JIRA] (ISPN-1884) expose hibernate search search factory statistics jmx

by Mathieu Lachance (JIRA)

Mathieu Lachance created ISPN-1884: -------------------------------------- Summary: expose hibernate search search factory statistics jmx Key: ISPN-1884 URL: https://issues.jboss.org/browse/ISPN-1884 Project: Infinispan Issue Type: Feature Request Components: JMX, reporting and management Affects Versions: 5.1.1.FINAL Reporter: Mathieu Lachance Assignee: Manik Surtani it is possible to add jmx hook to obtain Hibernate Search SearchFactory Statistics by using this property : <indexing enabled="true" indexLocalOnly="true"> <properties> <property name="hibernate.search.jmx_enabled" value="true" /> </properties> </indexing> tough this property does not allow multiple registration (one registration per cache). it would be nice to wrap the Statistics object from HibernateSearch into the actual cache object mbean. i guess the implementation could look like this : // get search factory statistics org.hibernate.search.stat.Statistics statistics = Search.getSearchManager(org.infinispan.Cache).getSearchFactory().getStatistics(); // wrap search factory statistics SearchFactoryStatisticMBean mbean = new SearchFactoryStatisticMBeanImpl(statistics); // expose mbean ManagementFactory.getPlatformMBeanServer().registerMBean(new ObjectName("..."), mbean); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

6
15
0 / 0

[JBoss JIRA] (ISPN-2259) Async store is too slow

by Radim Kolář (JIRA)

Radim Kolář created ISPN-2259: --------------------------------- Summary: Async store is too slow Key: ISPN-2259 URL: https://issues.jboss.org/browse/ISPN-2259 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 5.1.6.FINAL Environment: Windows XP, Java 7 Reporter: Radim Kolář Assignee: Mircea Markus Async support for loaders is too slow. I am writing 1000 items into cache backed by jdbm with modification queue size 10000 and it takes 6 seconds. -- 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

12 years, 3 months

3
7
0 / 0

[JBoss JIRA] Created: (ISPN-1174) Using an AsyncStore with passivating eviction creates a time window in which entries might not be found

by Sanne Grinovero (JIRA)

Using an AsyncStore with passivating eviction creates a time window in which entries might not be found ------------------------------------------------------------------------------------------------------- Key: ISPN-1174 URL: https://issues.jboss.org/browse/ISPN-1174 Project: Infinispan Issue Type: Bug Components: Eviction, Locking and Concurrency Affects Versions: 5.0.0.CR5 Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 5.0.0.CR6 When loading from an AsyncStore we should check if the entry is not in process of being written to the underlying store (somewhere in the async queue), as at this point it was already removed from the container and if not yet written on the store it might not be found otherwise. See also http://infinispan.markmail.org/search/#query:%20from%3A%22Manik%20Surtani... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

4
19
0 / 0

[JBoss JIRA] (ISPN-2293) Develop an async cache store stress test

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2293: -------------------------------------- Summary: Develop an async cache store stress test Key: ISPN-2293 URL: https://issues.jboss.org/browse/ISPN-2293 Project: Infinispan Issue Type: Task Components: Loaders and Stores Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.2.0.CR1 Similar to what Sanne's done for the Lucene cache store stress test, but more focused on the async cache store which makes it easier to spot issues related to the async 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

12 years, 3 months

3
7
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2012