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

Ariel Weisberg commented on CASSANDRA-15059:
--------------------------------------------

I think that's a good way to resolve the concerns with destabilizing 4.0 while 
still getting the benefit of doing more runtime checking.

Maybe we want to create a single property (not specific to Gossip?)  for this 
class of conditional logging or assertion. That way when we invoke the tests we 
don't have to specify multiple properties to specify whether we want fail fast 
or logging behavior if we want this elsewhere.

 I would be +1 if we did that.

I agree the refactor is a bit of an ask for 4.0, but I don't see it as a 
refactor really. It's all type system stuff with no actual changes to what 
methods are invoked and where. It's really just bucketing every method in 
Gossiper into a interfaces and instead of having code use Gossiper.instance we 
would have it use the appropriate interface reference. That is pretty low risk 
although the LOC churn would not be small.

> 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