January 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5987) Create concurrent topology switch under failover unit test

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5987?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5987: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta1) > Create concurrent topology switch under failover unit test > ---------------------------------------------------------- > > Key: ISPN-5987 > URL: https://issues.jboss.org/browse/ISPN-5987 > Project: Infinispan > Issue Type: Task > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.2.0.CR1 > > > Create a unit test for ISPN-5879. > Matej built a very interesting one [here|https://raw.githubusercontent.com/mcimbora/infinispan/da971738e326a7...] but needs some further work. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5990) Upgrade javassist dependency in protostream to ensure java 8 compatibility

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5990?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5990: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta1) > Upgrade javassist dependency in protostream to ensure java 8 compatibility > -------------------------------------------------------------------------- > > Key: ISPN-5990 > URL: https://issues.jboss.org/browse/ISPN-5990 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.0.0.Final, 8.1.0.Alpha1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.2.0.CR1, 8.0.3.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6015) Query DSL should support groupBy for multi-valued properties

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6015?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6015: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta1) > Query DSL should support groupBy for multi-valued properties > ------------------------------------------------------------ > > Key: ISPN-6015 > URL: https://issues.jboss.org/browse/ISPN-6015 > Project: Infinispan > Issue Type: Feature Request > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.2.0.CR1, 8.2.0.Final > > > If a groupBy property is multivalued the entity will belong to multiple groups, one for each distinct value. > Current implementation in 8.0.x and 8.1.x does not allow this and instead of providing invalid results grouping by multivalued property was disallowed (see ISPN-6008). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6098?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6098: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta1) > 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.CR1 > > > 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)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6092) Upgrade to Hibernate Search 5.5.2.Final

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6092?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6092: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta1) > Upgrade to Hibernate Search 5.5.2.Final > --------------------------------------- > > Key: ISPN-6092 > URL: https://issues.jboss.org/browse/ISPN-6092 > Project: Infinispan > Issue Type: Component Upgrade > Components: Embedded Querying, Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6094?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6094: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta1) > 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.CR1 > > > 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)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6091) Upgrade to Apache Lucene 5.4.1

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6091?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6091: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta1) > Upgrade to Apache Lucene 5.4.1 > ------------------------------ > > Key: ISPN-6091 > URL: https://issues.jboss.org/browse/ISPN-6091 > Project: Infinispan > Issue Type: Component Upgrade > Components: Embedded Querying, Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6084?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6084: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta1) > 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.CR1, 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)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6069) Unify the continuous query API for remote and embedded mode

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6069?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6069: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta1) > Unify the continuous query API for remote and embedded mode > ----------------------------------------------------------- > > Key: ISPN-6069 > URL: https://issues.jboss.org/browse/ISPN-6069 > Project: Infinispan > Issue Type: Enhancement > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.2.0.CR1, 8.2.0.Final > > > The api for registering/unregistering the listener is slightly different in embedded vs remote. The listener interface is identical, but resides in different packages. These need to be unified to ensure a nicer usability. Making ContinousQuery an interface instead of a class and moving it along with the listener interface to the query DSL package is a possible option. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6051) ClusterExpirationManager missing locking

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6051?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6051: ------------------------------- Fix Version/s: 8.2.0.CR1 (was: 8.2.0.Beta1) > ClusterExpirationManager missing locking > ---------------------------------------- > > Key: ISPN-6051 > URL: https://issues.jboss.org/browse/ISPN-6051 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: William Burns > Fix For: 8.2.0.CR1 > > > Because {{ClusterExpirationManager.handleLifespanExpired()}} doesn't lock the entry and the value is actually read in the async thread, the created {{RemoveExpiredCommand}} sometimes uses a newer value written by another thread. > Could be fixed by using {{DataContainer.compute()}} to check expiration and create the {{RemoveExpirationCommand}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2016