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

Reply via email to