[
https://issues.apache.org/jira/browse/CASSANDRA-13993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16427566#comment-16427566
]
Aleksey Yeschenko commented on CASSANDRA-13993:
-----------------------------------------------
Disregard my last comment here, I was wrong, by a big margin. My apologies.
As implemented currently, we are going to send PINGs potentially to 3.11/3.0 -
unless we switch to gating by version, which we do sometimes. And if you pick a
verb after {{UNUSED_5}}, it would error out on 3.11/3.0 side. So, again, unless
we gate by version (on which - see below*), we need to pick an ordinal that is
within the range of 3.0/3.11 - so one of {{UNUSED_1..5}} verbs.
The latest still supported release is 2.2, which has only 3 {{UNUSED}} verbs.
To be super paranoid and maxmimise the # of available {{UNUSED}} verbs in case
of bad things happening that would force us to introduce new verbs in old
versions - which is very unlikely to happen, but did happen before, we should
use one of {{UNUSED_4}} or {{UNUSED_5}} verbs here, in my opinion.
But not inserting a verb before {{UNUSED_1}} like it is now - it's essentially
taking up {{UNUSED_1}} verb, but confusing things between 4.0 and 3.0/3.11,
where everything would slide by one and might introduce mistakes.
* So I was thinking about a major upgrade bounce scenario. Think the first ever
node to upgrade to 4.0 in a cluster of 3.0 nodes - will send out pings to every
node, but receive no pongs, correct? So every node until a threshold will have
a significantly longer bounce. Do we care about this case?
> Add optional startup delay to wait until peers are ready
> --------------------------------------------------------
>
> Key: CASSANDRA-13993
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13993
> Project: Cassandra
> Issue Type: Improvement
> Components: Lifecycle
> Reporter: Jason Brown
> Assignee: Jason Brown
> Priority: Minor
> Fix For: 4.0
>
>
> When bouncing a node in a large cluster, is can take a while to recognize the
> rest of the cluster as available. This is especially true if using TLS on
> internode messaging connections. The bouncing node (and any clients connected
> to it) may see a series of Unavailable or Timeout exceptions until the node
> is 'warmed up' as connecting to the rest of the cluster is asynchronous from
> the rest of the startup process.
> There are two aspects that drive a node's ability to successfully communicate
> with a peer after a bounce:
> - marking the peer as 'alive' (state that is held in gossip). This affects
> the unavailable exceptions
> - having both open outbound and inbound connections open and ready to each
> peer. This affects timeouts.
> Details of each of these mechanisms are described in the comments below.
> This ticket proposes adding a mechanism, optional and configurable, to delay
> opening the client native protocol port until some percentage of the peers in
> the cluster is marked alive and connected to/from. Thus while we potentially
> slow down startup (delay opening the client port), we alleviate the chance
> that queries made by clients don't hit transient unavailable/timeout
> exceptions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
