[
https://issues.apache.org/jira/browse/CASSANDRA-7704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14096779#comment-14096779
]
Benedict commented on CASSANDRA-7704:
-------------------------------------
Not cleaning up resources is really not ideal in my book, however there is
absolutely no reason we need to cancel with interruption - note this does *not*
always result in a cancelled state if it ran, only if it was in the middle of
running at the time (but still completed), and this can be fixed by not
permitting it to be interrupted. However this is not the problem - in the test
it will often be the case that the task was _genuinely_ successfully cancelled.
In my opinion the test is broken, since previously there was _no_ guarantee
that all cancellations would run (although the cancellation in the test case
will); after the last task completes successfully the scheduled tasks were all
removed from the queue (but *not* cancelled), so the behaviour of the future in
this case would be to never return, which is much more surprising and
inconsistent in my book.
I'm not entirely sure what the offending line is intended to test, anyway?
> FileNotFoundException during STREAM-OUT triggers 100% CPU usage
> ---------------------------------------------------------------
>
> Key: CASSANDRA-7704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7704
> Project: Cassandra
> Issue Type: Bug
> Reporter: Rick Branson
> Assignee: Benedict
> Attachments: 7704.20.v2.txt, 7704.txt, backtrace.txt, other-errors.txt
>
>
> See attached backtrace which was what triggered this. This stream failed and
> then ~12 seconds later it emitted that exception. At that point, all CPUs
> went to 100%. A thread dump shows all the ReadStage threads stuck inside
> IntervalTree.searchInternal inside of CFS.markReferenced().
--
This message was sent by Atlassian JIRA
(v6.2#6252)
