[
https://issues.apache.org/jira/browse/CASSANDRA-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15514498#comment-15514498
]
Jason Brown commented on CASSANDRA-8457:
----------------------------------------
I've pushed a couple commits to the same branch, and kicked off tests now.
re: {{LegacyClientHandler}} - it ended up not being too difficult to parse the
message "header" to get through to the payload size. It's implemented in
{{MessageReceiveHandler}}. I've also removed {{LegacyClientHandler}} and the
original message in classes, {{MessageInHandler}} and
{{AppendingByteBufInputStream}} and their tests.
re: flush: yup, dumped my counter thing, and am using
{{FlushConsolidationHandler}}. There's still some finer semantics/behaviors to
groom over wrt flushing, but this is a better solution already.
re: {{MessagingService}} As a short term solution, I created an interface to
abstract out all the blocking IO vs netty related stuffs in MS. It's not a
thing of beauty, but hopefully it's cleaner and won't need to live all that
long. I hope we can live with this during the scope of the review.
> 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)
