January 2013 - infinispan-issues - Jboss List Archives

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

by Robert Stupp (JIRA)

[ https://issues.jboss.org/browse/ISPN-2240?page=com.atlassian.jira.plugin.... ] Robert Stupp commented on ISPN-2240: ------------------------------------ I'm currently preparing the test (have to change our app again to let it work with infinispan) and collect reference performance numbers (using the vendor's "earthenware" products). Hope to have test results on Tuesday (approx.). > 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, 5.1.x > Reporter: Robert Stupp > Assignee: Mircea Markus > Priority: Critical > Fix For: 5.2.0.Final > > Attachments: ISPN-2240_fix_TimeoutExceptions.patch, 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2632) Uneven request balancing after node crash

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2632?page=com.atlassian.jira.plugin.... ] Work on ISPN-2632 started by Galder Zamarreño. > Uneven request balancing after node crash > ----------------------------------------- > > Key: ISPN-2632 > URL: https://issues.jboss.org/browse/ISPN-2632 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.0.CR1 > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 5.2.0.CR2, 5.2.0.Final > > > This is a new manifestation of ISPN-1995, but in this case this happens after killing only one node: the hot rod requests aren't very well balanced. > these runs still manifest also ISPN-2550 and it may be cause of this bug. > The uneven balancing of requests can be seen here: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2654) NPE in CacheStatement when no cache is in session

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-2654?page=com.atlassian.jira.plugin.... ] Martin Gencur commented on ISPN-2654: ------------------------------------- Verified with 5.2.0.CR1 > NPE in CacheStatement when no cache is in session > ------------------------------------------------- > > Key: ISPN-2654 > URL: https://issues.jboss.org/browse/ISPN-2654 > Project: Infinispan > Issue Type: Bug > Components: CLI > Affects Versions: 5.2.0.Beta6 > Reporter: Michal Linhard > Assignee: Tristan Tarrant > Fix For: 5.2.0.CR1 > > > steps to reproduce: > 0. run JDG server, create user with adduser script, then run jdg-cli.sh > 1. $ connect user@localhost > 2. $ cache -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-132) FIFO queue support

by Arne Degenring (JIRA)

[ https://issues.jboss.org/browse/ISPN-132?page=com.atlassian.jira.plugin.s... ] Arne Degenring commented on ISPN-132: ------------------------------------- I'm sure that many projects would have a use case for an Infinispan-based distributed queue. E.g. in one of our components, everything is based on Infinispan, and the usage of an additional technology such as JMS for the queuing (required only for one very specific part), would increase the overall complexity too much. (Other distributed data frameworks such as Hazelcast do provide distributed queue implementations in addition to the distributed map...) > FIFO queue support > ------------------ > > Key: ISPN-132 > URL: https://issues.jboss.org/browse/ISPN-132 > Project: Infinispan > Issue Type: Feature Request > Components: Core API, Fine-grained API > Reporter: Bryan Grunow > Assignee: Manik Surtani > Fix For: 7.0.0.Final > > > Add support for retrieving entries from the cache (simple API and Tree API) via insertion (FIFO) order. > For example, cache.getNext(); would return the next entry in the queue. -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2640) Design security functionality in Infinispan

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2640?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2640: -------------------------------- Priority: Blocker (was: Critical) > Design security functionality in Infinispan > ------------------------------------------- > > Key: ISPN-2640 > URL: https://issues.jboss.org/browse/ISPN-2640 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Adrian Nistor > Priority: Blocker > Fix For: 5.3.0.Final > > > This serves as a prerequisite for ISPN-143 which is to be implemented in 6.0. The task is about gathering the requirements, discussing them with the community and sum them up in a requirements document. OpenShift team should also be involved in defining the requirements for this. -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2689) Support storage of indexes of Apache Lucene 4

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-2689?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-2689: --------------------------------------- Good timing! http://lists.jboss.org/pipermail/infinispan-dev/2013-January/011839.html > Support storage of indexes of Apache Lucene 4 > --------------------------------------------- > > Key: ISPN-2689 > URL: https://issues.jboss.org/browse/ISPN-2689 > Project: Infinispan > Issue Type: Feature Request > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 6.0.0.Beta1, 6.0.0.Final > > Attachments: ISPN-2689-hack-main.diff, ISPN-2689-hack-test.diff > > > The current Lucene Directory supports Lucene version from 2.9 to 3.6, > but Lucene 4 made consistent changes which might need a new module. -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2689) Support storage of indexes of Apache Lucene 4

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-2689?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-2689: --------------------------------------- [~jaley] thanks a lot, I'll have a look as soon as I can, which unfortunately means next week! Hope that's good for you. Others are welcome to comment as well. > Support storage of indexes of Apache Lucene 4 > --------------------------------------------- > > Key: ISPN-2689 > URL: https://issues.jboss.org/browse/ISPN-2689 > Project: Infinispan > Issue Type: Feature Request > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 6.0.0.Beta1, 6.0.0.Final > > Attachments: ISPN-2689-hack-main.diff, ISPN-2689-hack-test.diff > > > The current Lucene Directory supports Lucene version from 2.9 to 3.6, > but Lucene 4 made consistent changes which might need a new module. -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2463) Clean up Configuration API in test suites

by Navin Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-2463?page=com.atlassian.jira.plugin.... ] Navin Surtani updated ISPN-2463: -------------------------------- Affects Version/s: 5.3.0.Final (was: 5.2.0.Beta4) > Clean up Configuration API in test suites > ----------------------------------------- > > Key: ISPN-2463 > URL: https://issues.jboss.org/browse/ISPN-2463 > Project: Infinispan > Issue Type: Task > Components: Test Suite > Affects Versions: 5.3.0.Final > Reporter: Navin Surtani > Assignee: Navin Surtani > Labels: configuration, testsuite > Fix For: 6.0.0.Final > > > The test-suite currently uses older, previous implementations of configuring Infinispan. These approaches are currently deprecated and for ease of maintenance it would be useful to clean up the approach used to configure Infinispan within the test-suite. -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2463) Clean up Configuration API in test suites

by Navin Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-2463?page=com.atlassian.jira.plugin.... ] Navin Surtani updated ISPN-2463: -------------------------------- Fix Version/s: 5.3.0.Final (was: 6.0.0.Final) > Clean up Configuration API in test suites > ----------------------------------------- > > Key: ISPN-2463 > URL: https://issues.jboss.org/browse/ISPN-2463 > Project: Infinispan > Issue Type: Task > Components: Test Suite > Affects Versions: 5.3.0.Final > Reporter: Navin Surtani > Assignee: Navin Surtani > Labels: configuration, testsuite > Fix For: 5.3.0.Final > > > The test-suite currently uses older, previous implementations of configuring Infinispan. These approaches are currently deprecated and for ease of maintenance it would be useful to clean up the approach used to configure Infinispan within the test-suite. -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2604) When accessing a Transient entry on one node of a cluster, make sure all copies are touched to avoid expiration

by Ray Tsang (JIRA)

[ https://issues.jboss.org/browse/ISPN-2604?page=com.atlassian.jira.plugin.... ] Ray Tsang commented on ISPN-2604: --------------------------------- I feel that's true in a library mode perspective. But in terms of hotrod client/server, if remoteCache.get(key) occurs all in node-1 and then after expiry it accesses it from node-2, the entry would be unavailable on node-2 even though it's still on node-1. from remoteCache's perspective, the entry shouldn't have expired. In worst case scenario, max idle would behave just like lifespan in remote cache. That being said, I think ISPN-2655 would prevent the above scenario from hotrod's perspective. > When accessing a Transient entry on one node of a cluster, make sure all copies are touched to avoid expiration > --------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2604 > URL: https://issues.jboss.org/browse/ISPN-2604 > Project: Infinispan > Issue Type: Enhancement > Components: Distributed Cache > Reporter: Ray Tsang > Assignee: Mircea Markus > Fix For: 8.0.0.Final > > > Following up on this topic, this is what I have setup: > 2 nodes in cluster (either lib mode or remote) - node-1 and node-2 > a cache setup as distributed, synchronous (dist_sync) > cache.put("key", "value", -1, TimeUnit.MILLISECONDS, 2000, TimeUnit.MILLISECONDS); > for (i = 0; i < 10; i++) { > sleep(1000) // sleep 1 second > cache.get("key"); > } > Here is the weird thing, after a few gets, I'm starting to get null results. This doesn't occur when there is only 1 node in the cluster. > I'm suspecting that, w/ when accessing the data, it could be accessing 1 of the 2 nodes based on load balancing. > cache.get("key") -> node-1 // 1s > cache.get("key") -> node-1 // 2s > cache.get("key") -> node-1 // 3s > cache.get("key") -> node-2 // oops, this is already expired on node-2 > It would be nice to be able to make sure when accessing an entry from one node, the entry copies on other nodes are also "touched". -- 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

13 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2013