[
https://issues.apache.org/jira/browse/CASSANDRA-18749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756564#comment-17756564
]
Stefan Miklosovic commented on CASSANDRA-18749:
-----------------------------------------------
for completeness, builds for 5.0
j17
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2974/workflows/bfd67694-f469-49d9-8010-04e0eb3160e6
j11
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2974/workflows/1aa5af96-d74c-4bcb-b2fb-2f230bdbdb1a
> Expose bootstrap failure state via JMX
> --------------------------------------
>
> Key: CASSANDRA-18749
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18749
> Project: Cassandra
> Issue Type: Task
> Components: Observability/JMX
> Reporter: Jaydeepkumar Chovatia
> Assignee: Jaydeepkumar Chovatia
> Priority: Normal
> Fix For: 5.x
>
>
> Similar to how we have exposed a node's decommissioning via JMX as part of
> CASSANDRA-18555.
> This ticket will address the same when a new node joins (i.e., bootstrap).
> When a node is bootstrapped, an error is thrown back to the caller if any
> failure happens.
> But Cassandra's bootstrap takes considerable time ranging from minutes to
> hours to days. There are various scenarios in that the caller may need to
> probe the status again:
> * The caller times out
> * It is not possible to keep the caller hanging for such a long time
> And If the caller does not know what happened internally, then it cannot
> retry, etc., leading to other issues.
> So, in this ticket, a new nodetool/JMX option will be exposed that can be
> invoked by the caller anytime, and it will return the correct status.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
