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

Reply via email to