March 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6098) LockManagerTest.testMultipleCounterStripped random failures

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-6098?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-6098: ------------------------------------ Fix Version/s: 8.2.0.Final (was: 8.2.0.CR1) > LockManagerTest.testMultipleCounterStripped random failures > ----------------------------------------------------------- > > Key: ISPN-6098 > URL: https://issues.jboss.org/browse/ISPN-6098 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Fix For: 8.2.0.Final > > > Doesn't appear to fail in CI, but I did get a couple failures running the test on my machine: > {noformat} > 17:42:29,998 ERROR (testng-LockManagerTest:) [UnitTestTestNGListener] Test testMultipleCounterStripped(org.infinispan.lock.LockManagerTest) failed. > java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 60 seconds for key key-6 and requestor Thread[pool-1127-thread-4,5,main]. Lock is held by null > at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_60] > at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_60] > at org.infinispan.lock.LockManagerTest.doMultipleCounterTest(LockManagerTest.java:193) ~[test-classes/:?] > at org.infinispan.lock.LockManagerTest.testMultipleCounterStripped(LockManagerTest.java:67) ~[test-classes/:?] > Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 60 seconds for key key-6 and requestor Thread[pool-1127-thread-4,5,main]. Lock is held by null > at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:236) ~[classes/:?] > at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$CompositeLockPromise.lock(DefaultLockManager.java:305) ~[classes/:?] > at org.infinispan.lock.LockManagerTest.lambda$doMultipleCounterTest$483(LockManagerTest.java:163) ~[test-classes/:?] > ... 4 more > {noformat} > In another run, I got a deadlock that I think is related in {{InfinispanLockTest}}: > {noformat} > "testng-InfinispanLockTest" #19 prio=5 os_prio=0 tid=0x00007ff7f0eeb800 nid=0x4f5d waiting on condition [0x00007ff770da5000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0000000084202448> (a java.util.concurrent.FutureTask) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429) > at java.util.concurrent.FutureTask.get(FutureTask.java:191) > at org.infinispan.lock.InfinispanLockTest.testSingleCounter(InfinispanLockTest.java:262) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:348) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:38) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Locked ownable synchronizers: - <0x0000000082875cc0> (a java.util.concurrent.ThreadPoolExecutor$Worker) > "pool-1011-thread-7" #9840 prio=5 os_prio=0 tid=0x00007ff7380da000 nid=0x75f7 waiting on condition [0x00007ff698409000] > java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000842020d8> (a java.util.concurrent.CompletableFuture$Signaller) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1695) > at java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3323) > at java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1775) > at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) > at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:74) > at org.infinispan.util.concurrent.locks.impl.InfinispanLock$LockPlaceHolder.lock(InfinispanLock.java:319) > at org.infinispan.lock.InfinispanLockTest.lambda$testSingleCounter$509(InfinispanLockTest.java:243) > at org.infinispan.lock.InfinispanLockTest$$Lambda$516/1905052434.call(Unknown Source) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Locked ownable synchronizers: - <0x00000000842021f8> (a java.util.concurrent.ThreadPoolExecutor$Worker) > "pool-1011-thread-6" #9839 prio=5 os_prio=0 tid=0x00007ff738130800 nid=0x75f6 waiting on condition [0x00007ff699c21000] > java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000842023a0> (a java.util.concurrent.CompletableFuture$Signaller) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1695) > at java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3323) > at java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1775) > at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) > at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:74) > at org.infinispan.util.concurrent.locks.impl.InfinispanLock$LockPlaceHolder.lock(InfinispanLock.java:319) > at org.infinispan.lock.InfinispanLockTest.lambda$testSingleCounter$509(InfinispanLockTest.java:243) > at org.infinispan.lock.InfinispanLockTest$$Lambda$516/1905052434.call(Unknown Source) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Locked ownable synchronizers: - <0x0000000084202468> (a java.util.concurrent.ThreadPoolExecutor$Worker) > {noformat} > I also suggest using {{AbstractInfinispanTest.fork()}} instead of an explicit {{ExecutorService}} in both tests, because without the test name in the thread name it's impossible to filter the test logs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6094) Use security actions to read system properties for configuration

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-6094?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-6094: ------------------------------------ Fix Version/s: 8.2.0.Final (was: 8.2.0.CR1) > Use security actions to read system properties for configuration > ---------------------------------------------------------------- > > Key: ISPN-6094 > URL: https://issues.jboss.org/browse/ISPN-6094 > Project: Infinispan > Issue Type: Task > Components: Core, Embedded Querying > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.0.Final > > > Infinispan uses system properties for out-of-band settings that weren't deemed important enough to have a proper configuration attribute: > * infinispan.arrays.debug > * infinispan.unsafe.force_multicast > * infinispan.compat (obsolete?) > * infinispan.debugDependencies > * infinispan.stagger.delay (introduced with ISPN-825) > * org.infinispan.query.indexmanager.LockAcquiringBackend.MAX_QUEUE_SIZE > We should use a {{SecurityActions}} class to access these properties instead of {{Boolean.getBoolean()}} and {{Integer.getInteger()}}. We should also document these system properties, and evaluate moving them to the proper configuration. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6084) Continuous query should reject queries with orderBy

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-6084?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-6084: ------------------------------------ Fix Version/s: (was: 8.2.0.CR1) > Continuous query should reject queries with orderBy > --------------------------------------------------- > > Key: ISPN-6084 > URL: https://issues.jboss.org/browse/ISPN-6084 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 8.1.0.Final, 8.0.2.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Minor > Fix For: 8.2.0.Final > > > Current behaviour it that orderBy is silently ignored. Disallowing this and throwing an exception would be preferable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6050) RemoveExpiredCommand should check the version

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-6050?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-6050: ------------------------------------ Fix Version/s: 8.2.0.Final (was: 8.2.0.CR1) > RemoveExpiredCommand should check the version > --------------------------------------------- > > Key: ISPN-6050 > URL: https://issues.jboss.org/browse/ISPN-6050 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: William Burns > Fix For: 8.2.0.Final > > > Cluster-wide expiration is not optional, so it cannot require versioning. But it could and it should use versions when they are present, e.g. with HotRod. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6055) Performance regression in replicated reads after ISPN-5465 and ISPN-5878

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-6055?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-6055: ------------------------------------ Fix Version/s: (was: 8.2.0.CR1) > Performance regression in replicated reads after ISPN-5465 and ISPN-5878 > ------------------------------------------------------------------------ > > Key: ISPN-6055 > URL: https://issues.jboss.org/browse/ISPN-6055 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Jakub Markos > Assignee: Dan Berindei > Fix For: 8.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6252) Upgrade to Apache Lucene 5.5

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-6252?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-6252: ------------------------------------ Fix Version/s: 8.2.0.Final (was: 8.2.0.CR1) > Upgrade to Apache Lucene 5.5 > ---------------------------- > > Key: ISPN-6252 > URL: https://issues.jboss.org/browse/ISPN-6252 > Project: Infinispan > Issue Type: Component Upgrade > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 8.2.0.Final > > > Apache Lucene 5.5 is released now, and is "drop-in compatible" with versions 5.3 and 5.4 so you don't have to wait for an Hibernate Search release. > It's also being the last one for the 5.x series before 6, so I expect that we'll see some more micro releases for maintenance but essentially that this will be some form of long term commitment. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6219) An interruption during a MassIndexer run should exit early

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-6219?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-6219: ------------------------------------ Fix Version/s: 8.2.0.Final (was: 8.2.0.CR1) > An interruption during a MassIndexer run should exit early > ---------------------------------------------------------- > > Key: ISPN-6219 > URL: https://issues.jboss.org/browse/ISPN-6219 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Reporter: Sanne Grinovero > Fix For: 8.2.0.Final > > > Methods like {{IndexUpdater.updateIndex()}} correctly check for interruption state to skip some work but they don't trigger an early exit from the indexing loop so we'd still be consuming all of the data stream. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6224) Simplify configuration of Query with Indexing Affinity

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-6224?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-6224: ------------------------------------ Fix Version/s: 8.2.0.Final (was: 8.2.0.CR1) > Simplify configuration of Query with Indexing Affinity > ------------------------------------------------------ > > Key: ISPN-6224 > URL: https://issues.jboss.org/browse/ISPN-6224 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Sanne Grinovero > Fix For: 8.2.0.Final > > > We should try to enable the "Index Affinity" capabilities in an easier way from a configuration point of view. > For example I wonder if the capabilities provided by the {{AffinityPartitioner}} could not be enabled by default, for example automatically decorating any user defined {{HashFunctionPartitioner}} so that people can't neither forget to enable it, nor override it. > Second, should it be enabled by default when the cache configuration suggests it, for example in most clustered caches? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6212) InfinispanBackendQueueProcessor is assuming all IndexManager implementations are DirectoryBasedIndexManager

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-6212?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-6212: ------------------------------------ Fix Version/s: 8.2.0.Final (was: 8.2.0.CR1) > InfinispanBackendQueueProcessor is assuming all IndexManager implementations are DirectoryBasedIndexManager > ----------------------------------------------------------------------------------------------------------- > > Key: ISPN-6212 > URL: https://issues.jboss.org/browse/ISPN-6212 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying > Reporter: Sanne Grinovero > Fix For: 8.2.0.Final > > > See also the FIXME note in {{InfinispanBackendQueueProcessor}}: this needs to be cleaned up. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6220) Speedup index rebuilds but using ADD rather than UPDATE statements when safe

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-6220?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-6220: ------------------------------------ Fix Version/s: 8.2.0.Final (was: 8.2.0.CR1) > Speedup index rebuilds but using ADD rather than UPDATE statements when safe > ---------------------------------------------------------------------------- > > Key: ISPN-6220 > URL: https://issues.jboss.org/browse/ISPN-6220 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Sanne Grinovero > Fix For: 8.2.0.Final > > > The {{DistributedExecutorMassIndexer}} relies on update commands to index the new entries, but when we just run a full purge of the index it should be safe to use Add commands instead if we know that there aren't concurrent updates. > The lack of concurrent updates might be tricky but I think we can find such a condition when using Affinity as the index is being fully controlled by the current indexing engine, similarly to the checks to see if it's safe to use an NRT workspace. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2016