[
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)
