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

Reply via email to