[jira] [Comment Edited] (CASSANDRA-8457) nio MessagingService

["Jason Brown (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966390#comment-15966390 ] 

Jason Brown edited comment on CASSANDRA-8457 at 4/12/17 7:58 PM:
-----------------------------------------------------------------

[~aweisberg] So, I've kicked this idea around a bit (haven't coded anything up yet), but I thought about using something like {{ExpiringMap}} for the {{QueuedMessage}} s, and when the message times out, either update a (possibly new) field in the {{QueuedMessage}} or failing the {{ChannelPromise}}. Failing the {{ChannelPromise}} is a bit racy as the netty event loop may be in the process of actually serializing and sending the message, and failing the promise (from another thread) might not be great as we're actually doing the work. Meanwhile, updating some new {{volatile}} field in the {{QueuedMessage}} requires yet another volatile update on the send path (better than a synchronized call for sure, but ...).

{{ExpiringMap}}, of course, creates more garbage ({{CacheableObject}}), and has it's own internal {{ConcurrentHashMap}}, with more volatiles and such. Not sure if this is great idea, but it's the current state of my thinking? Thoughts?


was (Author: jasobrown):
[~aweisberg] So, I've kicked this idea around a bit (haven't coded anything up yet), but I thought about using something like {{ExpiringMap}} for the {{QueuedMessages}}s, and when the message times out, either update a (possibly new) field in the {{QueuedMessage}} or failing the {{ChannelPromise}}. Failing the {{ChannelPromise}} is a bit racy as the netty event loop may be in the process of actually serializing and sending the message, and failing the promise (from another thread) might not be great as we're actually doing the work. Meanwhile, updating some new {{volatile}} field in the {{QueuedMessage}} requires yet another volatile update on the send path (better than a synchronized call for sure, but ...).

{{ExpiringMap}}, of course, creates more garbage ({{CacheableObject}}), and has it's own internal {{ConcurrentHashMap}}, with more volatiles and such. Not sure if this is great idea, but it's the current state of my thinking? Thoughts?

> 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.15#6346)