[JBoss JIRA] (ISPN-6038) ClientAsymmetricClusterTest.testAsymmetricCluster random failures
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/ISPN-6038?page=com.atlassian.jira.plugin.... ]
Romain Pelisse updated ISPN-6038:
---------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4081
> ClientAsymmetricClusterTest.testAsymmetricCluster random failures
> -----------------------------------------------------------------
>
> Key: ISPN-6038
> URL: https://issues.jboss.org/browse/ISPN-6038
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols, Test Suite - Server
> Reporter: Dan Berindei
> Assignee: Romain Pelisse
> Priority: Minor
> Labels: testsuite_stability
> Fix For: 9.0.0.Beta1
>
>
> {{ClientAsymmetricClusterTest.testAsymmetricCluster}} is failing since the ISPN-5981 fix, which enabled {{pingOnStartup}} by default, and now returns {{null}} if the first server to be pinged doesn't have the cache defined.
> {noformat}
> 10:23:07,862 WARN (testng-ClientAsymmetricClusterTest:) [Codec21] ISPN004005: Error received from the server: org.infinispan.server.hotrod.CacheNotFoundException: Cache with name 'asymmetricCache' not found amongst the configured caches
> 10:23:07,862 ERROR (testng-ClientAsymmetricClusterTest:) [UnitTestTestNGListener] Test testAsymmetricCluster(org.infinispan.client.hotrod.ClientAsymmetricClusterTest) failed.
> java.lang.NullPointerException
> at org.infinispan.client.hotrod.ClientAsymmetricClusterTest.testAsymmetricCluster(ClientAsymmetricClusterTest.java:38) ~[test-classes/:?]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ISPN-7051) Intermittent RpcException during PUTs and GETs when topology changes
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7051?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-7051:
-----------------------------------
So, what happens:
1. C does a staggered get to B, A (current topologyId=4)
2. B responds first with SuccessfulResponse{null} - I am not sure why it does not have the value if it's an owner according to readCH
3. A responds second with actual value, but the delayed response is ignored
4. C retries to find the entry, routing accoring to pendingCH - and the owner there is C
5. C sends the command to itself, but as local node is filtered out in JGroupsTransport, it returns empty response map
A correct solution should involve a check if the actual owners - self isn't empty (or even better, forcing to send remote commands with remote recipients only), but the logic is changed in https://github.com/infinispan/infinispan/pull/4564 so I am not sure if we should invest more into this, rather than do a review & merge on the above mentioned PR.
> Intermittent RpcException during PUTs and GETs when topology changes
> --------------------------------------------------------------------
>
> Key: ISPN-7051
> URL: https://issues.jboss.org/browse/ISPN-7051
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Gustavo Fernandes
> Priority: Critical
> Attachments: trace-jgroups.tgz.part-00, trace-jgroups.tgz.part-01, trace-jgroups.tgz.part-02, trace-jgroups.tgz.part-03, trace-jgroups.tgz.part-04, trace.tgz
>
>
> The commit https://github.com/infinispan/infinispan/commit/6ae4e2e7707285287ef753661... seems to be introducing intermittent errors during gets and puts under topology changes
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ISPN-7051) Intermittent RpcException during PUTs and GETs when topology changes
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7051?page=com.atlassian.jira.plugin.... ]
Radim Vansa edited comment on ISPN-7051 at 9/27/16 6:57 AM:
------------------------------------------------------------
So, what happens:
1. C does a staggered get to B, A (current topologyId=4)
2. B responds first with SuccessfulResponse\{null\} - I am not sure why it does not have the value if it's an owner according to readCH
3. A responds second with actual value, but the delayed response is ignored
4. C retries to find the entry, routing accoring to pendingCH - and the owner there is C
5. C sends the command to itself, but as local node is filtered out in JGroupsTransport, it returns empty response map
A correct solution should involve a check if the actual owners - self isn't empty (or even better, forcing to send remote commands with remote recipients only), but the logic is changed in https://github.com/infinispan/infinispan/pull/4564 so I am not sure if we should invest more into this, rather than do a review & merge on the above mentioned PR.
was (Author: rvansa):
So, what happens:
1. C does a staggered get to B, A (current topologyId=4)
2. B responds first with SuccessfulResponse{null} - I am not sure why it does not have the value if it's an owner according to readCH
3. A responds second with actual value, but the delayed response is ignored
4. C retries to find the entry, routing accoring to pendingCH - and the owner there is C
5. C sends the command to itself, but as local node is filtered out in JGroupsTransport, it returns empty response map
A correct solution should involve a check if the actual owners - self isn't empty (or even better, forcing to send remote commands with remote recipients only), but the logic is changed in https://github.com/infinispan/infinispan/pull/4564 so I am not sure if we should invest more into this, rather than do a review & merge on the above mentioned PR.
> Intermittent RpcException during PUTs and GETs when topology changes
> --------------------------------------------------------------------
>
> Key: ISPN-7051
> URL: https://issues.jboss.org/browse/ISPN-7051
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Gustavo Fernandes
> Priority: Critical
> Attachments: trace-jgroups.tgz.part-00, trace-jgroups.tgz.part-01, trace-jgroups.tgz.part-02, trace-jgroups.tgz.part-03, trace-jgroups.tgz.part-04, trace.tgz
>
>
> The commit https://github.com/infinispan/infinispan/commit/6ae4e2e7707285287ef753661... seems to be introducing intermittent errors during gets and puts under topology changes
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months