You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "David Capwell (Jira)" <ji...@apache.org> on 2019/12/16 18:11:00 UTC
[jira] [Comment Edited] (CASSANDRA-15450) in-jvm dtest cluster
uncaughtExceptions propagation of exception goes to the wrong instance, it
uses cluster generation when it should be using the instance id
[ https://issues.apache.org/jira/browse/CASSANDRA-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16997508#comment-16997508 ]
David Capwell edited comment on CASSANDRA-15450 at 12/16/19 6:10 PM:
---------------------------------------------------------------------
{quote}should we add a test?{quote}
The issue happens when the second cluster created in the JVM attempts to monitor the kill request; to replicate this in a single DC we would need to create a cluster, then create a second cluster, attempt to cause the first node to be killed (disk failure policy), then wait for the failure to propagate.
I don't think that test would add a lot of value, and the current test infrastructure is able to detect this and cause periodic failures; making the test flaky at the moment. I am in favor of not adding a new test for this, but relying on the fact that the test stop being flaky. [~ifesdjeen] sound good to you?
This test was added by CASSANDRA-15332 which was not back ported to the 3.x branches. In order to get this patch to apply in 3.x we would first need to back port CASSANDRA-15332. Speaking to [~ifesdjeen] it sounds like we want 3.x and 4.x dtests to share the same API, so we should first backport CASSANDRA-15332 before applying this patch to 3.x.
was (Author: dcapwell):
{quote} should we add a test?\{quote}
The issue happens when the second cluster created in the JVM attempts to monitor the kill request; to replicate this in a single DC we would need to create a cluster, then create a second cluster, attempt to cause the first node to be killed (disk failure policy), then wait for the failure to propagate.
I don't think that test would add a lot of value, and the current test infrastructure is able to detect this and cause periodic failures; making the test flaky at the moment. I am in favor of not adding a new test for this, but relying on the fact that the test stop being flaky. [~ifesdjeen] sound good to you?
This test was added by CASSANDRA-15332 which was not back ported to the 3.x branches. In order to get this patch to apply in 3.x we would first need to back port CASSANDRA-15332. Speaking to [~ifesdjeen] it sounds like we want 3.x and 4.x dtests to share the same API, so we should first backport CASSANDRA-15332 before applying this patch to 3.x.
> in-jvm dtest cluster uncaughtExceptions propagation of exception goes to the wrong instance, it uses cluster generation when it should be using the instance id
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-15450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15450
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
> Reporter: David Capwell
> Assignee: David Capwell
> Priority: Normal
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In AbstractCluster.uncaughtExceptions, we attempt to get the instance from the class loader and used the “generation”. This value is actually the cluster id, so causes tests to fail when multiple tests share the same JVM; it should be using the “id” field which represents the instance id relative to the cluster.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org