[CASSANDRA-14503] Internode connection management is race-prone

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Won't Fix
• Fix Version/s: 4.0-alpha1, 4.0
• Component/s: Legacy/Streaming and Messaging
• Labels: pull-request-available
• Severity: Normal
• Assignee: Jason Brown
• Reporter: Sergio Bossa

Authors

Jason Brown

Reviewers

Benedict Elliott Smith, Dinesh Joshi

• Created: 07/Jun/18 12:56
• Updated: 16/Mar/22 12:06
• Resolved: 12/Jun/19 15:34

Description

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.

Issue Links

• blocks: CASSANDRA-14747 Test Messaging Refactor with: 200 node, compression=none, encryption=none, coalescing=off
• is duplicated by: CASSANDRA-14507 OutboundMessagingConnection backlog is not fully written in case of race conditions
• links to: Cassandra 4.0 testing with CASSANDRA-14503 fixes
• links to: GitHub Pull Request #264
• links to: GitHub Pull Request #289