July 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7272) Remove replication statistics from RpcManagerImpl

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7272?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7272: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > Remove replication statistics from RpcManagerImpl > ------------------------------------------------- > > Key: ISPN-7272 > URL: https://issues.jboss.org/browse/ISPN-7272 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.1.6.Final, 9.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.2.0.Final > > > The replication statistics exposed by {{RpcManagerImpl}} are too low-level. For instance, in non-transactional caches, the times of the RPCs from the primary to the backups are counted both on the primary and on the originator (as part of the originator-to-primary RPC). They also aren't split by operation, like the {{CacheMgmtInterceptor}} statistics, which makes them even less useful. > The triangle algorithm changes things again, but only for distributed caches, so there is now one more way of interpreting the {{RpcManagerImpl}} statistics. It would be better to remove them altogether. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7167) ExampleConfigsIT.testTopologyConfigRackAttribute random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7167?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7167: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > ExampleConfigsIT.testTopologyConfigRackAttribute random failures > ----------------------------------------------------------------- > > Key: ISPN-7167 > URL: https://issues.jboss.org/browse/ISPN-7167 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 9.2.0.Final > > > {noformat} > java.lang.AssertionError: Unexpected number of entries in server1: 0 > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.infinispan.server.test.configs.ExampleConfigsIT.verifyTopologyHinting(ExampleConfigsIT.java:482) > at org.infinispan.server.test.configs.ExampleConfigsIT.testTopologyConfigRackAttribute(ExampleConfigsIT.java:419) > {noformat} > The test is also inconsistent about the names of the servers, sometimes it starts counting from 0 and sometimes it starts counting from 1. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7159) CompleteShutdownDistRetryTest.testRetryAfterCompleteShutdown random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7159?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7159: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > CompleteShutdownDistRetryTest.testRetryAfterCompleteShutdown random failures > ---------------------------------------------------------------------------- > > Key: ISPN-7159 > URL: https://issues.jboss.org/browse/ISPN-7159 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 9.2.0.Final > > > {noformat} > java.lang.AssertionError: expected:<two> but was:<null> > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:101) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:108) > at org.infinispan.client.hotrod.retry.CompleteShutdownDistRetryTest.testRetryAfterCompleteShutdown(CompleteShutdownDistRetryTest.java:58) > {noformat} > I think the problem is that killing node 0 can make node 2's key move from node 2 to node 1, and then it's lost after node 1 is also killed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7145) Rebase JGroups subsystem on WildFly 10.1

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7145?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7145: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > Rebase JGroups subsystem on WildFly 10.1 > ---------------------------------------- > > Key: ISPN-7145 > URL: https://issues.jboss.org/browse/ISPN-7145 > Project: Infinispan > Issue Type: Task > Components: Server > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.2.0.Final > > > Our JGroups subsystem is based on the corresponding subsystem from WildFly 9. We should rebase on WildFly 10, most notably in order to pick up the WFCORE-1127 fix. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7139) Consistent prefix in property names of Hot Rod client configurations

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7139?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7139: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > Consistent prefix in property names of Hot Rod client configurations > -------------------------------------------------------------------- > > Key: ISPN-7139 > URL: https://issues.jboss.org/browse/ISPN-7139 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Remote Protocols > Reporter: Sanne Grinovero > Fix For: 9.2.0.Final > > > Most Hot Rod configuration properties use the prefix {{infinispan.client.hotrod.}} which makes it easy to recognize them. > Some properties don't use the prefix though, such as all those related to connection pooling, e.g. {{maxActive}}, {{maxTotal}}, .. > This makes it hard to read Hot Rod specific configuration properties from alternative sources. In particular we'd like to embed such properties in an Hibernate configuration file (for Hibernate OGM) but the fact that some properties need special handling forces us to keep a list of these to have special care, rather than being able to use a prefix like it is done in most such cases. > It should be easy to prefix all the properties, and deprecate the names. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[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.2.0.Final (was: 9.1.0.Final) > 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.2.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7098) FunctionalDistributionTest.testDistributionFromPrimaryOwner random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7098?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7098: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > FunctionalDistributionTest.testDistributionFromPrimaryOwner random failures > --------------------------------------------------------------------------- > > Key: ISPN-7098 > URL: https://issues.jboss.org/browse/ISPN-7098 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 9.2.0.Final > > > {{FunctionalDistributionTest.testDistributionFromPrimaryOwner}} assumes 100ms is enough for the command to be executed on both backup owners, but that's not always true -- e.g. when TRACE logging is enabled. > {noformat} > 15:27:36,079 TRACE (async-thread-Test-NodeC-p36570-t1:[]) [InvocationContextInterceptor] Invoked with command ReadWriteKeyCommand {key=testDistributionFromPrimaryOwner, flags=[]} and InvocationContext [org.infinispan.context.SingleKeyNonTxInvocationContext@44ffeec2] > 15:27:36,124 TRACE (async-thread-Test-NodeC-p36570-t1:[]) [JGroupsTransport] dests=[Test-NodeC-21089, Test-NodeD-31203], command=SingleRpcCommand{cacheName='dist', command=ReadWriteKeyCommand {key=testDistributionFromPrimaryOwner, flags=[]}}, mode=ASYNCHRONOUS, timeout=15000 > 15:27:36,140 TRACE (async-thread-Test-NodeC-p36570-t1:[]) [DefaultDataContainer] Store MetadataImmortalCacheEntry{key=testDistributionFromPrimaryOwner, value=1, metadata=MetaParamsInternalMetadata{params=MetaParams{metas=[]}}} in container > 15:27:36,144 TRACE (Incoming-1,Test-NodeD-31203:[]) [InvocationContextInterceptor] Invoked with command ReadWriteKeyCommand {key=testDistributionFromPrimaryOwner, flags=[]} and InvocationContext [org.infinispan.context.SingleKeyNonTxInvocationContext@73111d9] > 15:27:36,241 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.functional.FunctionalDistributionTest.testDistributionFromPrimaryOwner > java.lang.NullPointerException > at org.infinispan.functional.FunctionalDistributionTest.lambda$iterate$8(FunctionalDistributionTest.java:101) ~[test-classes/:?] > at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) ~[?:1.8.0_101] > at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) ~[?:1.8.0_101] > at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) ~[?:1.8.0_101] > at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374) ~[?:1.8.0_101] > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) ~[?:1.8.0_101] > at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) ~[?:1.8.0_101] > at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) ~[?:1.8.0_101] > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:1.8.0_101] > at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) ~[?:1.8.0_101] > at org.infinispan.functional.FunctionalDistributionTest.iterate(FunctionalDistributionTest.java:102) ~[test-classes/:?] > at org.infinispan.functional.FunctionalDistributionTest.doTestDistribution(FunctionalDistributionTest.java:80) ~[test-classes/:?] > at org.infinispan.functional.FunctionalDistributionTest.testDistributionFromPrimaryOwner(FunctionalDistributionTest.java:46) ~[test-classes/:?] > 15:27:36,259 TRACE (Incoming-1,Test-NodeD-31203:[]) [DefaultDataContainer] Store MetadataImmortalCacheEntry{key=testDistributionFromPrimaryOwner, value=1, metadata=MetaParamsInternalMetadata{params=MetaParams{metas=[]}}} in container > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

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.2.0.Final (was: 9.1.0.Final) > 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.2.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

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.2.0.Final (was: 9.1.0.Final) > 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.2.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

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.2.0.Final (was: 9.1.0.Final) > 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.2.0.Final > > > {{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)

7 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2017