[ 
https://issues.apache.org/jira/browse/CASSANDRA-15059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812769#comment-16812769
 ] 

Blake Eggleston commented on CASSANDRA-15059:
---------------------------------------------

{quote}
Future wise this doesn't do anything to address the underlying fragility in how 
Gossiper doesn't document what is safe to call from outside the Gossip thread 
and what isn't. It also doesn't validate the correct thread is running a given 
method.
{quote}

I’ve been thinking about this a lot, and I think it would be safer if we didn’t 
do this.

Adding some preconditions isn’t going to fix the underlying fragility of 
Gossiper. Given the “realities” of the Gossiper class, I think it would end up 
causing more harm that good. Just starting to pull on that thread reveals at 
least one situation where we modify gossip state out of the gossip stage that 
makes sense (on startup). There are probably one or two more (at least), and 
I’d hate to break a nodetool command or something.

> Gossiper#markAlive can race with Gossiper#markDead
> --------------------------------------------------
>
>                 Key: CASSANDRA-15059
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15059
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Cluster/Gossip
>            Reporter: Blake Eggleston
>            Assignee: Blake Eggleston
>            Priority: Normal
>
> The Gossiper class is not threadsafe and assumes all state changes happen in 
> a single thread (the gossip stage). Gossiper#convict, however, can be called 
> from the GossipTasks thread. This creates a race where calls to 
> Gossiper#markAlive and Gossiper#markDead can interleave, corrupting gossip 
> state. Gossiper#assassinateEndpoint has a similar problem, being called from 
> the mbean server thread.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to