February 2017 - infinispan-issues

[JBoss JIRA] (ISPN-7117) ContinuousQuery.addContinuousQueryListener should fail if cache is async

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7117?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7117: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > ContinuousQuery.addContinuousQueryListener should fail if cache is async > ------------------------------------------------------------------------ > > Key: ISPN-7117 > URL: https://issues.jboss.org/browse/ISPN-7117 > Project: Infinispan > Issue Type: Bug > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.CR2, 9.0.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7057) Refactor StatsChannelHandler to support null transport

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7057?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7057: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Refactor StatsChannelHandler to support null transport > ------------------------------------------------------ > > Key: ISPN-7057 > URL: https://issues.jboss.org/browse/ISPN-7057 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Reporter: Sebastian Łaskawiec > Fix For: 9.0.0.CR2 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7042) Deprecate the tree module

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7042?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7042: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Deprecate the tree module > ------------------------- > > Key: ISPN-7042 > URL: https://issues.jboss.org/browse/ISPN-7042 > Project: Infinispan > Issue Type: Task > Components: Build process, Core > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.CR2, 9.0.0.Final > > > We haven't fixed a single tree bug in 2016, and a single one in 2015 ([https://issues.jboss.org/browse/ISPN-4661]). There appear to be some people still using it and hitting bugs ([http://stackoverflow.com/questions/29673123/infinispan-treecache-not-gett...]), so we should make it clear that we're not supporting it any more. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7061) Allow using HOST header for routing in to REST interface

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7061?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7061: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Allow using HOST header for routing in to REST interface > -------------------------------------------------------- > > Key: ISPN-7061 > URL: https://issues.jboss.org/browse/ISPN-7061 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Reporter: Sebastian Łaskawiec > Fix For: 9.0.0.CR2 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7026) CacheClusterJoinTest.testIsCoordinator random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7026?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7026: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > CacheClusterJoinTest.testIsCoordinator random failures > ------------------------------------------------------ > > Key: ISPN-7026 > URL: https://issues.jboss.org/browse/ISPN-7026 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 9.0.0.CR2 > > > {{CacheClusterJoinTest.testIsCoordinator}} assumes that once {{JGroupsTransport}} received a view, {{JGroupsTransport.isCoordinator()}} returns the correct value. > However, only {{JGroupsTransfer.viewAccepted}} is synchronized, {{isCoordinator()}} is not, so the main thread can see {{isCoordinator() == false}} even after {{getMembers().get(0) == self}}. > {noformat} > 19:32:27,555 DEBUG (Incoming-1,Test-NodeD-36891:[]) [JGroupsTransport] New view accepted: [Test-NodeD-36891|2] (1) [Test-NodeD-36891] > 19:32:27,556 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.api.CacheClusterJoinTest.testIsCoordinator > java.lang.AssertionError > at org.infinispan.api.CacheClusterJoinTest.testIsCoordinator(CacheClusterJoinTest.java:65) ~[test-classes/:?] > 19:32:27,555 DEBUG (Incoming-1,Test-NodeD-36891:[]) [JGroupsTransport] Joined: [], Left: [Test-NodeC-35712] > {noformat} > It would be nice if {{isCoordinator()}}, {{getCoordinator()}}, and {{getMembers()}} were more in sync, even though the view can always change between two calls. The simplest way to do this would be to implement {{isCoordinator()}} and {{getCoordinator()}} on top of {{getMembers()}} and remove their fields, since they're not use in performance-sensitive code. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6976) Log#iterationClosed should not use INFO level logging

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6976?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6976: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Log#iterationClosed should not use INFO level logging > ----------------------------------------------------- > > Key: ISPN-6976 > URL: https://issues.jboss.org/browse/ISPN-6976 > Project: Infinispan > Issue Type: Enhancement > Reporter: Sanne Grinovero > Priority: Minor > Fix For: 9.0.0.CR2 > > > I'm seeing lots of: > INFO RemoteCloseableIterator:69 - ISPN004046: Successfully closed remote iterator 'ae8525ce-a1f2-4dd8-b365-cce77af47656' > This is better suited for DEBUG level as it refers to normal operations. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7011) @AfterClass cleanup doesn't work with @InTransactionMode

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7011?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7011: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > @AfterClass cleanup doesn't work with @InTransactionMode > -------------------------------------------------------- > > Key: ISPN-7011 > URL: https://issues.jboss.org/browse/ISPN-7011 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Labels: testsuite_stability > Fix For: 9.0.0.CR2 > > > Very much like ISPN-7003, TestNG's {{TestMethodWorker.invokeAfterClassMethods}} never sees an empty list of methods in {{m_classMethodMap}}. That happens because {{m_classMethodMap}} is populated before our {{ChainMethodInterceptor}} had a chance to filter the methods (e.g. when a test method has an {{@InTransactionMode}} annotation). > Normally this is not a problem because each test has a different name, and the test suite tolerates some leaked managers. But when you run a test like {{PutForExternalReadTest}} with {{-Dtest.infinispan.shortTestName=true}}, you get this failure: > {noformat} > java.lang.IllegalStateException: Two tests with the same name running in parallel: test > at org.infinispan.test.fwk.TestResourceTracker.testStarted(TestResourceTracker.java:88) > at org.infinispan.test.AbstractInfinispanTest.testClassStarted(AbstractInfinispanTest.java:115) > 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:498) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) > at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138) > at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:175) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:107) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7008) IllegalLifeCycleStateException from BlockingRunnable.isReady() escapes to originator

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7008?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7008: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > IllegalLifeCycleStateException from BlockingRunnable.isReady() escapes to originator > ------------------------------------------------------------------------------------ > > Key: ISPN-7008 > URL: https://issues.jboss.org/browse/ISPN-7008 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Alpha4, 8.2.4.Final > Reporter: Dan Berindei > Fix For: 9.0.0.CR2 > > > The ISPN-5539 fix caught {{IllegalLifecycleStateException}} in {{BlockingRunnable.run()}} and sent a {{CacheNotFoundResponse}} to the originator instead. However, exceptions thrown from {{BlockingRunnable.isReady()}} are not caught, and are instead sent back to the originator. An example stack trace is available in the WFLY-7029 description. > In this case, the exception was thrown directly when the inbound invocation handler tried to submit the command to the remote commands executor. But I see a related problem in {{BlockingTaskAwareExecutorServiceImpl.ControllerThread.run()}}, which stops with the first exception from {{isReady()}}. For {{IllegalLifecycleStateException}} it's probably ok, but for other exceptions it should continue processing new tasks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6997) PessimisticTxPartitionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6997?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6997: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > PessimisticTxPartitionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition random failures > ----------------------------------------------------------------------------------------------- > > Key: ISPN-6997 > URL: https://issues.jboss.org/browse/ISPN-6997 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 9.0.0.CR2 > > > The test starts with a cluster of 4 nodes, and splits it in 2 partitions while a transaction is trying to lock a key. After the transaction fails, it checks that the transaction has been cleaned up properly. > On one of the owners, {{transactionTable.cleanupLeaverTransactions}} is being called only before the split and after the merge, never with the list of members during the split. That means it never sees the transaction as an orphan, and doesn't remove it. > {noformat} > 15:16:18,893 TRACE (testng-PTPAMDRT:[]) [PTPAMDRT] Local tx=[], remote tx=[GlobalTx:PTPAMDRT-NodeI-3337:28616], for cache PTPAMDRT-NodeJ-27814 > 15:16:18,893 ERROR (testng-PTPAMDRT:[]) [TestSuiteProgress] Test failed: org.infinispan.partitionhandling.PTPAMDRT.testOriginatorIsolatedPartition > java.lang.AssertionError: There are pending transactions! > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.8.8.jar:?] > at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:223) ~[test-classes/:?] > at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:519) ~[test-classes/:?] > at org.infinispan.test.MultipleCacheManagersTest.assertNoTransactions(MultipleCacheManagersTest.java:794) ~[test-classes/:?] > at org.infinispan.partitionhandling.BaseTxPartitionAndMergeTest.finalAsserts(BaseTxPartitionAndMergeTest.java:96) ~[test-classes/:?] > at org.infinispan.partitionhandling.BasePessimisticTxPartitionAndMergeTest.doTest(BasePessimisticTxPartitionAndMergeTest.java:82) ~[test-classes/:?] > at org.infinispan.partitionhandling.tionAndMergeDuringRuntimeTest.testOriginatorIsolatedPartition(PessimisticTxPartitionAndMergeDuringRuntimeTest.java:33) ~[test-classes/:?] > {noformat} > {{OptimisticTxPartitionAndMergeDuringCommitTest.testPrimaryOwnerIsolatedPartition}} has similar random failures. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6971) Use JChannel directly instead of going through MessageDispatcher

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6971?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6971: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Use JChannel directly instead of going through MessageDispatcher > ---------------------------------------------------------------- > > Key: ISPN-6971 > URL: https://issues.jboss.org/browse/ISPN-6971 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 9.0.0.CR2 > > > JGroups changed its serialization in 4.0, and even when using MessageDispatcher we still have to provide a JGroups-style marshaller for deserializing RPC responses. If we used JChannel directly, we could avoid this, and we'd have more control over how we process responses. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 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 February 2017