-
Notifications
You must be signed in to change notification settings - Fork 40.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CassandraHealthIndicator runs a query that fails on some Consistency Levels #20709
Conversation
@adutra Please sign the Contributor License Agreement! Click here to manually synchronize the status of this Pull Request. See the FAQ for frequently asked questions. |
@adutra Thank you for signing the Contributor License Agreement! |
The system keyspace has a replication factor of 1 and is local to each node; it is therefore recommended to query system.local with a consistency level of ONE or LOCAL_ONE. Stronger consistency levels may result in an Unavailable error, but this does not mean that the node is down. See gh-20709
@@ -52,8 +56,7 @@ public CassandraHealthIndicator(CassandraOperations cassandraOperations) { | |||
|
|||
@Override | |||
protected void doHealthCheck(Health.Builder builder) throws Exception { | |||
SimpleStatement select = SimpleStatement.newInstance("SELECT release_version FROM system.local"); | |||
ResultSet results = this.cassandraOperations.getCqlOperations().queryForResultSet(select); | |||
ResultSet results = this.cassandraOperations.getCqlOperations().queryForResultSet(SELECT); | |||
if (results.isFullyFetched()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally think that this check is inaccurate here since this method will always return true for this query. As a consequence, the code beneath the if block is never reached and the health indicator never reports the release version. But since this is not related to the fix I left it for another PR.
@adutra thank you very much for making your first contribution to Spring Boot. We had to fix this one in |
@snicoll I would simply remove the check, since the query can either fail or return one row exactly. The reactive version of the check does that btw. Speaking of reactive, |
Does that apply to the previous version of the SDK as well? |
Yes. |
The system keyspace has a replication factor of 1 and is local to each node; it is therefore recommended to query system.local with a consistency level of ONE or LOCAL_ONE.
Stronger consistency levels may result in an Unavailable error, but this does not mean that the node is down.
This patch does not include additional tests because it is hard to test the change in a stubbed environment; obviously, the existing tests still pass. Let me know if I can contribute an integration test for that.