[ https://issues.apache.org/jira/browse/CASSANDRA-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16588759#comment-16588759 ]
Jason Brown edited comment on CASSANDRA-14503 at 8/22/18 11:48 AM: ------------------------------------------------------------------- Working on a solution that will also resolve the problems [~sbtourist] raised with CASSANDRA-14507. I've spoken with some of the netty maintainers and they've given me some solid advice how to rework {{OutboubndMessageConnection}}. was (Author: jasobrown): Working on a solution that will also resolve the problems [~sbtourist] raised with CASSANDRA-14507. I've spoken with some of the netty maintainers and they've given me some solid advice about to rework {{OutboubndMessageConnection}}. > Internode connection management is race-prone > --------------------------------------------- > > Key: CASSANDRA-14503 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14503 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging > Reporter: Sergio Bossa > Assignee: Jason Brown > Priority: Major > > Following CASSANDRA-8457, internode connection management has been rewritten > to rely on Netty, but the new implementation in > {{OutboundMessagingConnection}} seems quite race prone to me, in particular > on those two cases: > * {{#finishHandshake()}} racing with {{#close()}}: i.e. in such case the > former could run into an NPE if the latter nulls the {{channelWriter}} (but > this is just an example, other conflicts might happen). > * Connection timeout and retry racing with state changing methods: > {{connectionRetryFuture}} and {{connectionTimeoutFuture}} are cancelled when > handshaking or closing, but there's no guarantee those will be actually > cancelled (as they might be already running), so they might end up changing > the connection state concurrently with other methods (i.e. by unexpectedly > closing the channel or clearing the backlog). > Overall, the thread safety of {{OutboundMessagingConnection}} is very > difficult to assess given the current implementation: I would suggest to > refactor it into a single-thread model, where all connection state changing > actions are enqueued on a single threaded scheduler, so that state > transitions can be clearly defined and checked. -- 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