[JBoss JIRA] (ISPN-7159) CompleteShutdownDistRetryTest.testRetryAfterCompleteShutdown random failures
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7159?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7159:
------------------------------
Fix Version/s: 9.0.0.CR3
(was: 9.0.0.CR2)
> 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.0.0.CR3
>
>
> {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)
9 years, 1 month
[JBoss JIRA] (ISPN-7272) Remove replication statistics from RpcManagerImpl
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7272?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7272:
------------------------------
Fix Version/s: 9.0.0.CR3
(was: 9.0.0.CR2)
> 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: 9.0.0.Alpha4, 8.1.6.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.0.0.CR3
>
>
> 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)
9 years, 1 month
[JBoss JIRA] (ISPN-7400) Cache segment ownership information in DistributionManager
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7400?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7400:
------------------------------
Fix Version/s: 9.0.0.CR3
(was: 9.0.0.CR2)
> Cache segment ownership information in DistributionManager
> ----------------------------------------------------------
>
> Key: ISPN-7400
> URL: https://issues.jboss.org/browse/ISPN-7400
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.0.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: performance
> Fix For: 9.0.0.CR3
>
>
> ISPN-7029 introduced {{DistributionInfo}} to simplify limit the number of times we compute the location of a given key. We can go further and cache the {{DistributionInfo}} of each segment in {{DistributionManager}}, so that each operation only needs to compute the segment of its key.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7302) ClusteredConditionalCommandTest.testPutIfAbsentOnNonOwnerWithIgnoreReturnValues random failures
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7302?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7302:
------------------------------
Fix Version/s: 9.0.0.CR3
(was: 9.0.0.CR2)
> 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.0.0.CR3
>
>
> 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.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7396) Improve default bundle size and fragment size
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7396?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7396:
------------------------------
Fix Version/s: 9.0.0.CR3
(was: 9.0.0.CR2)
> 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.0.0.CR3
>
>
> 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.2.3#72005)
9 years, 1 month