February 2018 - infinispan-issues

[JBoss JIRA] (ISPN-6956) AffinityPartitioner enabled as default partitioner

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6956?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6956: ---------------------------------- Fix Version/s: 9.3.0.Final (was: 9.2.0.Final) > AffinityPartitioner enabled as default partitioner > -------------------------------------------------- > > Key: ISPN-6956 > URL: https://issues.jboss.org/browse/ISPN-6956 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 9.3.0.Final > > > Having the {{org.infinispan.distribution.ch.impl.AffinityPartitioner}} as default enabled {{KeyPartitioner}} will allow people to use the functionality offered by {{org.infinispan.distribution.ch.AffinityTaggedKey}} out of the box, without needing to enable it explicitly in configuration. > {{AffinityTaggedKey}} is used by Query but not only. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7401) AbstractProtocolServer relying on startDefaultCache

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7401?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7401: ---------------------------------- Fix Version/s: 9.3.0.Final (was: 9.2.0.Final) > AbstractProtocolServer relying on startDefaultCache > --------------------------------------------------- > > Key: ISPN-7401 > URL: https://issues.jboss.org/browse/ISPN-7401 > Project: Infinispan > Issue Type: Task > Components: Server > Reporter: Sanne Grinovero > Assignee: Tristan Tarrant > Fix For: 9.3.0.Final > > > The {{AbstractProtocolServer}} class is used/extended by various other tools, including testing infrastructure of OGM. > It currently is "booting" the system by starting the default cache. This concept needs an update. > See {{org.infinispan.server.core.AbstractProtocolServer.startDefaultCache()}} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7396) Improve default bundle size and fragment size

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7396?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7396: ---------------------------------- Fix Version/s: 9.3.0.Final (was: 9.2.0.Final) > Improve default bundle size and fragment size > --------------------------------------------- > > Key: ISPN-7396 > URL: https://issues.jboss.org/browse/ISPN-7396 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: performance > Fix For: 9.3.0.Final > > > If a UDP packet is split into multiple ethernet frames, the entire packet is lost. TCP avoids sending packets larger than an ethernet frame for us, but with a UDP transport, we need to consider the ethernet frame size when configuring {{UDP.max_bundle_size}} and {{FRAG2.frag_size}}. > Most modern networks should support jumbo frames with 9000 bytes, so we should set {{UDP.max_bundle_size=8000}} and {{FRAG2.frag_size=8500}} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7302) ClusteredConditionalCommandTest.testPutIfAbsentOnNonOwnerWithIgnoreReturnValues random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7302?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7302: ---------------------------------- Fix Version/s: 9.3.0.Final (was: 9.2.0.Final) > ClusteredConditionalCommandTest.testPutIfAbsentOnNonOwnerWithIgnoreReturnValues random failures > ----------------------------------------------------------------------------------------------- > > Key: ISPN-7302 > URL: https://issues.jboss.org/browse/ISPN-7302 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.0.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 9.3.0.Final > > > When the backup owner replies before the primary had a chance to load the value from persistence, the number of loads from the primary can be {{0}} at the time the test checks it. > {noformat} > 00:21:48,941 TRACE (testng-Test:[]) [JGroupsTransport] dests=[Test-NodeB-56150, Test-NodeA-13512], command=ClusteredGetCommand{key=Test-key, flags=[IGNORE_RETURN_VALUES]}, mode=WAIT_FOR_VALID_RESPONSE, timeout=15000 > 00:21:48,942 TRACE (jgroups-7,Test-NodeB-56150:[]) [InvocationContextInterceptor] Invoked with command GetCacheEntryCommand {key=Test-key, flags=[SKIP_REMOTE_LOOKUP, IGNORE_RETURN_VALUES]} and InvocationContext [org.infinispan.context.impl.NonTxInvocationContext@5f931934] > 00:21:48,943 TRACE (jgroups-7,Test-NodeB-56150:[]) [EntryFactoryImpl] Wrap Test-key for read. Entry=NullCacheEntry{} > 00:21:48,946 TRACE (jgroups-8,Test-NodeA-13512:[]) [InvocationContextInterceptor] Invoked with command GetCacheEntryCommand {key=Test-key, flags=[SKIP_REMOTE_LOOKUP, IGNORE_RETURN_VALUES]} and InvocationContext [org.infinispan.context.impl.NonTxInvocationContext@265c6c97] > 00:21:48,946 TRACE (jgroups-8,Test-NodeA-13512:[]) [PersistenceUtil] Loaded MarshalledEntryImpl{keyBytes=null, valueBytes=null, metadataBytes=null, key=Test-key, value=Test-value1, metadata=null, marshaller=org.infinispan.marshall.core.GlobalMarshaller@1aee2408} for key Test-key from persistence. > 00:21:48,946 TRACE (jgroups-8,Test-NodeA-13512:[]) [CommandAwareRpcDispatcher] About to send back response SuccessfulResponse{responseValue=ImmortalCacheValue {value=Test-value1}} for command ClusteredGetCommand{key=Test-key, flags=[IGNORE_RETURN_VALUES]} > 00:21:48,948 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.persistence.ClusteredTxConditionalCommandTest.testPutIfAbsentOnNonOwnerWithIgnoreReturnValues[tx=true] > java.lang.AssertionError: primary owner load expected:<1> but was:<0> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:170) ~[testng-6.8.8.jar:?] > at org.infinispan.persistence.ClusteredTxConditionalCommandTest.assertLoadAfterOperation(ClusteredTxConditionalCommandTest.java:46) ~[test-classes/:?] > at org.infinispan.persistence.ClusteredConditionalCommandTest.doTest(ClusteredConditionalCommandTest.java:121) ~[test-classes/:?] > at org.infinispan.persistence.ClusteredConditionalCommandTest.testPutIfAbsentOnNonOwnerWithIgnoreReturnValues(ClusteredConditionalCommandTest.java:242) ~[test-classes/:?] > 00:21:48,953 TRACE (jgroups-7,Test-NodeB-56150:[]) [PersistenceUtil] Loaded null for key Test-key from persistence. > 00:21:48,953 TRACE (jgroups-7,Test-NodeB-56150:[]) [CommandAwareRpcDispatcher] About to send back response SuccessfulResponse{responseValue=null} for command ClusteredGetCommand{key=Test-key, flags=[IGNORE_RETURN_VALUES]} > {noformat} > Possible fix: replace {{assertEquals}} with {{eventuallyEquals}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7288) Indexed queries with IN clause should use TermsQuery

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7288?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7288: ---------------------------------- Fix Version/s: 9.3.0.Final (was: 9.2.0.Final) > Indexed queries with IN clause should use TermsQuery > ---------------------------------------------------- > > Key: ISPN-7288 > URL: https://issues.jboss.org/browse/ISPN-7288 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 8.2.5.Final, 9.0.0.Beta1 > Reporter: Gustavo Fernandes > Assignee: Adrian Nistor > Fix For: 9.3.0.Final > > > There are two reasons for it: > * TermsQuery don't have a clause limit as Boolean Queries do (default is 1024) > * Performance for high number of clauses is vastly superior -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[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.3.0.Final (was: 9.2.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.3.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.5.0#75005)

6 years, 2 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.3.0.Final (was: 9.2.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.3.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.5.0#75005)

6 years, 2 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.3.0.Final (was: 9.2.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.3.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.5.0#75005)

6 years, 2 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.3.0.Final (was: 9.2.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.3.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.5.0#75005)

6 years, 2 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.3.0.Final (was: 9.2.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.3.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.5.0#75005)

6 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 February 2018