December 2012 - infinispan-issues

[JBoss JIRA] (ISPN-2656) Support RemoteCache.keySet()

by Ray Tsang (JIRA)

Ray Tsang created ISPN-2656: ------------------------------- Summary: Support RemoteCache.keySet() Key: ISPN-2656 URL: https://issues.jboss.org/browse/ISPN-2656 Project: Infinispan Issue Type: Feature Request Components: Remote protocols Reporter: Ray Tsang Assignee: Galder Zamarreño RemoteCache doesn't support keySet() method. A workaround is to use getBulk(). However, getBulk() returns both keys and values, which would be impractical with large dataset. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2650) Some Map Reduce tests are failing for Topology Aware nodes.

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-2650?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic commented on ISPN-2650: ------------------------------------------- Anna, lets not use BookSearchTest as using one test is enough to verify topology aware addresses and map/reduce! I mean, yes, we could make BookSearchTest work as well but it would be redundant. > Some Map Reduce tests are failing for Topology Aware nodes. > ----------------------------------------------------------- > > Key: ISPN-2650 > URL: https://issues.jboss.org/browse/ISPN-2650 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Affects Versions: 5.2.0.Beta5 > Reporter: Anna Manukyan > Assignee: Vladimir Blagojevic > > There are two test classes written for testing Map Reduce on TopologyAware nodes: > https://github.com/andyuk1986/infinispan/blob/DISTEXEC/core/src/test/java... > https://github.com/andyuk1986/infinispan/blob/DISTEXEC/core/src/test/java... > But both of them are failing. > The first one fails due to that the data is not replicated to other node (see https://issues.jboss.org/browse/ISPN-2629?focusedCommentId=12741469&page=...). > The second test fails due to not cancelled map reduce tasks (see https://issues.jboss.org/browse/ISPN-2629?focusedCommentId=12741470&page=...) . This one is really strange, as it fails only when I run it with the bunch of distexec tests, otherwise when separately run - it succeeds. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2655) Make HotRod client always read from the main data owner

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2655?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2655: -------------------------------- Fix Version/s: 5.2.0.Final > Make HotRod client always read from the main data owner > ------------------------------------------------------- > > Key: ISPN-2655 > URL: https://issues.jboss.org/browse/ISPN-2655 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.2.0.Beta6 > Reporter: Mircea Markus > Assignee: Tristan Tarrant > Fix For: 5.2.0.CR1, 5.2.0.Final > > > ISPN-2643 made the java Hot Rod client always write to the main owner. ATM the client picks a random owner for reading though. This read-load-balancing doesn't really help, as assuming the data is evenly spread, the amount of reads would be distributed uniformly across the cluster. OTOH forcing the client to always read from the main owner would guarantee red-consistency for *async* replicated caches. Even so read consistency might still be a problem when a node crashed, but still these is a much stronger guarantee and makes async replication usable in many more scenarios. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2655) Make HotRod client always read from the main data owner

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2655: ----------------------------------- Summary: Make HotRod client always read from the main data owner Key: ISPN-2655 URL: https://issues.jboss.org/browse/ISPN-2655 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.2.0.Beta6 Reporter: Mircea Markus Assignee: Tristan Tarrant Fix For: 5.2.0.CR1 ISPN-2643 made the java Hot Rod client always write to the main owner. ATM the client picks a random owner for reading though. This read-load-balancing doesn't really help, as assuming the data is evenly spread, the amount of reads would be distributed uniformly across the cluster. OTOH forcing the client to always read from the main owner would guarantee red-consistency for *async* replicated caches. Even so read consistency might still be a problem when a node crashed, but still these is a much stronger guarantee and makes async replication usable in many more scenarios. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2392) Optimize locking behaviour in non-transactional caches

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2392?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-2392: ------------------------------------- ISPN-2552 solved this problem for distributed caches. For replicated caches you can use a degenerated cache of distributed caches by setting numOwners to a very high value(e.g. 10000 given that your cluster doesn't have that many nodes). > Optimize locking behaviour in non-transactional caches > ------------------------------------------------------ > > Key: ISPN-2392 > URL: https://issues.jboss.org/browse/ISPN-2392 > Project: Infinispan > Issue Type: Enhancement > Components: Locking and Concurrency > Affects Versions: 5.2.0.Beta1 > Reporter: Thomas Fromm > Assignee: Mircea Markus > > Situation: REPL_SYNC cache, non transactional, locking isolation level NONE > Problem: when multiple threads trying to write same key on multiple nodes, the operation ends up mostly in locking timeouts > Mircea mentioned that the locking behaviour for non-tx caches could be optimized as well as for tx-caches or use the same mechanisms. > (One single lock, independed number of owners) -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2610) Use Query but disable automatic indexing

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2610?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2610: -------------------------------- Fix Version/s: (was: 5.2.0.CR1) > Use Query but disable automatic indexing > ---------------------------------------- > > Key: ISPN-2610 > URL: https://issues.jboss.org/browse/ISPN-2610 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 5.2.0.Final > > > The option known in Hibernate Search as > "hibernate.search.default.indexing_strategy" value="manual" > is not applied by Infinispan Query. > Workaround: use the SKIP_INDEXING flag > {code} > org.infinispan.context.Flag.SKIP_INDEXING{code} -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-2478) PutMapCommand not correctly removing previous types from indexes

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2478?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2478: -------------------------------- Fix Version/s: (was: 5.2.0.CR1) > PutMapCommand not correctly removing previous types from indexes > ---------------------------------------------------------------- > > Key: ISPN-2478 > URL: https://issues.jboss.org/browse/ISPN-2478 > Project: Infinispan > Issue Type: Bug > Components: Querying > Affects Versions: 5.1.8.Final > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 5.2.0.Final > > > We need to perform certain cleanup operations - potentially - on the return types of commands such as put and remove. In case of a putAll command, we're ignoring this requirement. -- 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

1
0
0 / 0

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

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2240?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2240: -------------------------------- Fix Version/s: (was: 5.2.0.CR1) > 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

12 years

1
0
0 / 0

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

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2240?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-2240: ------------------------------------- As per Manik, this shouldn't be an issue anymore given the locking fixes in this release. We need to run the test, check and close it though. > 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

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-1990) Preload sets the versions to null (repeatable read + write skew)

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1990?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1990: -------------------------------- Fix Version/s: 5.3.0.Final (was: 5.2.0.Final) (was: 5.2.0.CR1) > Preload sets the versions to null (repeatable read + write skew) > ---------------------------------------------------------------- > > Key: ISPN-1990 > URL: https://issues.jboss.org/browse/ISPN-1990 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.1.3.FINAL > Environment: Java 6 (64bits) > Infinispan 5.2.0-SNAPSHOT > MacOS > Reporter: Pedro Ruivo > Assignee: Mircea Markus > Labels: preload, skew, versioning, write > Fix For: 5.3.0.Final > > > I think I've spotted a issue when I use repeatable read with write skew check and I preload the cache. > > I've made a test case to reproduce the bug. It can be found here [1]. > The problem is that each keys preloaded is put in the container with version = null. When I try to commit a transaction, I get this exception: > > {code} > java.lang.IllegalStateException: Entries cannot have null versions! > at org.infinispan.container.entries.ClusteredRepeatableReadEntry.performWriteSkewCheck(ClusteredRepeatableReadEntry.java:44) > at org.infinispan.transaction.WriteSkewHelper.performWriteSkewCheckAndReturnNewVersions(WriteSkewHelper.java:81) > at org.infinispan.interceptors.locking.ClusteringDependentLogic$AllNodesLogic.createNewVersionsAndCheckForWriteSkews(ClusteringDependentLogic.java:133) > at org.infinispan.interceptors.VersionedEntryWrappingInterceptor.visitPrepareCommand(VersionedEntryWrappingInterceptor.java:64) > {code} > > I think that all info is in the test case, but if you need something let > me know. > > Cheers, > Pedro > [1] > https://github.com/pruivo/infinispan/blob/issue_1/core/src/test/java/org/... -- 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

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2012