[
https://issues.apache.org/jira/browse/CASSANDRA-14815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16705020#comment-16705020
]
Benedict edited comment on CASSANDRA-14815 at 11/30/18 4:55 PM:
----------------------------------------------------------------
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}}, as there are places in the state machine where a worker may also
unilaterally self-assign its state, knowing that nobody else would interfere
with it. In this 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 {{COWArrayList}} to
manage all of the worker threads.
Oh, also, a spelling nit in the {{MAGIC}} thread name indicator.
was (Author: benedict):
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}}, as there are places in the state machine where a worker may also
unilaterally self-assign its state, knowing that nobody else would interfere
with it. In this 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 {{COWArrayList}} 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]
