[
https://issues.apache.org/jira/browse/CASSANDRA-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966390#comment-15966390
]
Jason Brown commented on CASSANDRA-8457:
----------------------------------------
[~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)
