[
https://issues.apache.org/jira/browse/CASSANDRA-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963989#comment-15963989
]
Sylvain Lebresne commented on CASSANDRA-8457:
---------------------------------------------
bq. One remaining open issue is the current patch does not expire messages on
the producer thread, like what we used to do in
{{OutboundTcpConnection#enqueue}}
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.
{quote}
bq. In {{connectionTimeout()}}, what happens when a connection attempt timeout?
This is what {{OutboundTcpConnnection}} does, and I've replicated it here.
{quote}
Fair enough, but can't we at least log a warning? Sounds to me this would be an
improvement.
bq. TBH, I think both of these behaviors are incorrect
I agree and never fully understood the reasoning here, it's just not something
that seem to have created problem. Imo, there is just 2 cases:
# we have a version match: success, just use the connection.
# we have a version mismatch: disconnect from that connection and reconnect
with what we know will be a proper version. Don't do anything to the backlog,
we're still just negociating our connection and there is no reason to do
anything with outstanding messages.
Other than that, I had a quick look over the branch and it looks good, but
unfortunately you seem to have squashed everything with makes it really hard to
check the changes made since my last review, and I don't have the time right
now to redo a full careful read of the whole patch.
> 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)
