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

Reply via email to