[
https://issues.apache.org/jira/browse/CASSANDRA-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966293#comment-15966293
]
Ariel Weisberg commented on CASSANDRA-8457:
-------------------------------------------
bq. But was that even a good idea? I'm not convinced. The chance of a message
expiring on the sending node are low to start with, but having it expire on the
producer thread is kind of remote, and it doesn't feel like it's worth
bothering. Especially since we'll expire the message a tiny bit later when
processing it anyway. Overall, the benefit to code clarify of not checking for
expiration in too many places outweigh imo any benefit we'd have here.
In the context of the entire system maybe there are other mechanisms in play
that prevent messages from piling up. But without any mechanism what will
happen is that the messages can queue on the heap. With the old blocking
implementation the thread would eventually block because the TCP buffer is full
and with the NIO implementation the queued messages will not be pulled and
discarded because the socket will not signal ready to write.
I think it's important that a single slow node or network issue resulting in a
socket that isn't writable shouldn't allow an arbitrary amount of data to
collect on the heap. Right now there is nothing that can drop the data in that
scenario. The producer doesn't have to do the dropping in Netty land, but maybe
it makes more sense to make producers the victims for that work rather than
network threads which have other responsibilities.
> 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)
