cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8457) nio MessagingService
Date Mon, 19 Sep 2016 09:41:22 GMT

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

Mime
View raw message