[
https://issues.apache.org/jira/browse/CASSANDRA-14815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16705020#comment-16705020
]
Benedict commented on CASSANDRA-14815:
--------------------------------------
I've pushed a modified approach
[here|https://github.com/belliottsmith/cassandra/tree/14815]
It's a rare possible race condition, but unilaterally invoking set(Work.DEAD)
would not have guaranteed that the state was set to DEAD (there are places in
the state machine where a Thread may also unilaterally self-assign its state,
knowing that nobody else would interfere with it, in which case the state
change would be lost).
Perhaps this wouldn't be the end of the world, but if instead we introduce a
pool.shuttingDown boolean, and we check this only in the two places we might
need to - namely when we cannot assign ourselves work (which will be the case
if all executors have been shutdown), and when stopping ourselves (in case we
have somehow been very delayed in stopping, and so the original termination did
not signal us), we can also avoid introducing a new COWList to manage all of
the worker threads.
> SEPExecutor does not fully shut down
> ------------------------------------
>
> Key: CASSANDRA-14815
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14815
> Project: Cassandra
> Issue Type: Bug
> Components: Lifecycle
> Reporter: Alex Petrov
> Assignee: Alex Petrov
> Priority: Minor
>
> When trying to shut down an SEP Executor, a parked worked will still be
> parked on:
> {code}
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:88)
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
