[jira] [Commented] (CASSANDRA-8457) nio MessagingService

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

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

Sylvain Lebresne commented on CASSANDRA-8457:
---------------------------------------------

I'm still very much in the process of reviewing this and I'll have more on this later, but I wanted to provide a few early remarks instead of waiting to having fully digested it all:
* On {{LegacyClientHandler}}, I'm no sure it's really needed as current v3 messages actually do ship with their payload size. Now, granted said size is actually within the {{MessageIn/MessageOut}} object rather than the "framing" (the distinction between the 2 being a bit of an implementation detail though tbh), and there is a little bit more work to get to it than if it was the first thing in the "frame" as done by this patch for v4, but it should still be a lot easier than what {{LegacyClientHandler}} does. This also means the v4 format include twice the (exact same) payload size, which feels wasteful. On that v4 format, I actually think we could use to rethink that framing/message format a bit as we can easily save a few bytes, *but* it's definitively for a different ticket. But maybe for this thicket it's actually simpler to stick to the v3 format using the payload size that prefix said payload.
* Regarding the flushing, I agree relying on counters doesn't feel great. Why not just submit a flush task to the channel {{EventLoop}} (something like what [this|https://github.com/spotify/netty-zmtp/blob/master/src/main/java/com/spotify/netty4/util/BatchFlusher.java] does), which accordingly to Netty 4 thread model should ensure it happens after any outstanding other writes.
* The changes to {{MessagingService}} feels a bit ugly tbh given that we only ever use one implementation at runtime. I'd prefer making {{MessagingService}} abstract, abstracting the (relatively few) methods that use the connections, and have 2 sub-classes.


> nio MessagingService
> --------------------
>
>                 Key: CASSANDRA-8457
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8457
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Jonathan Ellis
>            Assignee: Jason Brown
>            Priority: Minor
>              Labels: netty, performance
>             Fix For: 4.x
>
>
> Thread-per-peer (actually two each incoming and outbound) is a big contributor to context switching, especially for larger clusters.  Let's look at switching to nio, possibly via Netty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)