[ https://issues.apache.org/jira/browse/CASSANDRA-18749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Miklosovic updated CASSANDRA-18749: ------------------------------------------ Fix Version/s: 5.0 5.1 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/acb4993cd0545ba4ce7bbb0a506c0cf46a0ac5ef Resolution: Fixed Status: Resolved (was: Ready to Commit) > 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.0, 5.1 > > > 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org