[
https://issues.apache.org/jira/browse/CASSANDRA-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15508103#comment-15508103
]
Jason Brown commented on CASSANDRA-8457:
----------------------------------------
re: {{LegacyClientHandler}}, and v3 vs v4 (or, "to frame or not to frame")
I'll admit this was a more difficult decision to make in this the patch. While
I'm not worried (right now) about the size occurring twice in the message (it
is only four bytes, and we could move it ;)), I was more concerned about being
able to fish out the payload size from *after* the message's parameters, for
which we have no size information. A quick scan of the current code shows we
only use the message headers for tracing and multi-DC mutations. In both cases,
the total data is small (tens of bytes). Of course, we don't know if we have
all the bytes for deserializing without a size field. In the case of having
headers in a message but not enough bytes in the buffer, we'll then need to
wait until more bytes come in and try deserailizing again. If we are OK with
that possibility (looping a couple times for more bytes, creating extra
garbage), then I have no major concerns about switching to that model,
especially if we avoid altering the protocol, which I agree would be great to
defer a different ticket if possible.
bq. Why not just submit a flush task to the channel {{EventLoop}} ...
Yeah, this makes sense, and is much more sane than my counters idea. I spoke
with the netty folks, and they recommended using netty's
{{FlushConsolidationHandler}} so I'll give that a shot before something custom
first. (That spotify example was instructive, though, so thanks!)
bq. The changes to {{MessagingService}} ...
tbh, I think we only need the two implementations until either CASSANDRA-12229
or CASSANDRA-8911 resolves how streaming is affected by this ticket (streaming
is effectively broken, for now, with the current internode messaging changes
because it shares the same listening socket with streaming). This assumes, of
course, that either of those tickets ship in the same rev as this one, which
might not be a great idea. So for now, at a minimum, I'll abstract out the
implementations, and we can throw out the legacy when when ready on either of
the other two tickets is ready as well. I'm open for disucssion on how/if
changes to internode messaging should affect streaming (i've discussed it a bit
on CASSANDRA-12229).
Thanks for the initial comments, I'll have some updated code in a day or so.
> 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)
