You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Brandon Williams (Jira)" <ji...@apache.org> on 2020/02/13 16:38:00 UTC
[jira] [Comment Edited] (CASSANDRA-15550) Fix flaky test
org.apache.cassandra.streaming.StreamTransferTaskTest
testFailSessionDuringTransferShouldNotReleaseReferences
[ https://issues.apache.org/jira/browse/CASSANDRA-15550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17036338#comment-17036338 ]
Brandon Williams edited comment on CASSANDRA-15550 at 2/13/20 4:37 PM:
-----------------------------------------------------------------------
This one has been around quite some time: ~4 years. In defense of that, it did sometimes take nearly 300 runs to reproduce it. The cause of this very tight race is that aborting the session is done asynchronously in nonPeriodicTasks, so we need to make sure that isn't pending when we call finishTasks since it checks the {code}completed{code} variable which won't be true until the task is aborted. Patch here: https://github.com/driftx/cassandra/tree/CASSANDRA-15550 to do this, but it does raise the question to me of should finishTasks actually _not_ finish if the abort hasn't set completed to true? Why would we need to call it in idempotent fashion? As evidenced by the test it seems like this is at least _potential_ for leaking a reference.
With the patch the test passed a couple thousand times.
was (Author: brandon.williams):
This one has been around quite some time: ~4 years. In defense of that, it did sometimes take nearly 300 runs to reproduce it. The cause of this very tight race is that aborting the session is done asynchronously in nonPeriodicTasks, so we need to make sure that isn't pending when we call finishTasks since it checks the `completed` variable which won't be true until the task is aborted. Patch here: https://github.com/driftx/cassandra/tree/CASSANDRA-15550 to do this, but it does raise the question to me of should finishTasks actually _not_ finish if the abort hasn't set completed to true? Why would we need to call it in idempotent fashion? As evidenced by the test it seems like this is at least _potential_ for leaking a reference.
With the patch the test passed a couple thousand times.
> Fix flaky test org.apache.cassandra.streaming.StreamTransferTaskTest testFailSessionDuringTransferShouldNotReleaseReferences
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-15550
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15550
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
> Reporter: David Capwell
> Assignee: Brandon Williams
> Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError: expected:<0> but was:<1>
> at org.apache.cassandra.streaming.StreamTransferTaskTest.testFailSessionDuringTransferShouldNotReleaseReferences(StreamTransferTaskTest.java:181)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> Failure was on java 11
--
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