[
https://issues.apache.org/jira/browse/CASSANDRA-15437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18077410#comment-18077410
]
Stefan Miklosovic edited comment on CASSANDRA-15437 at 4/30/26 6:55 PM:
------------------------------------------------------------------------
[~mbyrd]
I don't understand why we throw an exception when it is not possible to resolve
host to deliver these hints. We are not doing anything with that exception. I
mean ... throwing an exception _is fine_ it is just that I would expect we
catch it later and just log an error, no? Why do you want to have an exception
in the logs instead of an error log? Logging it on ERROR is just completely
fine. I just do not want to see the stacktrace. That is irrelevant for a user.
If you want that method still throw an exception, for whatever reason, alright,
I just do not see why it would need to be logged like that. There is nobody who
is reacting on this exception, we just propagate it up and that's it.
I change the implementation to show you what I meant by that here:
[https://github.com/apache/cassandra/pull/4775/changes]
We are actually already logging it here:
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StorageService.java#L3581]
So we 1) log 2) throw. Then that exception is propagated and logged on ERROR
again ... We can just log in ERROR, then throw if you want, fine, but we do not
need to propagate it further when we call Future.get eventually.
was (Author: smiklosovic):
[~mbyrd]
I don't understand why we throw an exception when it is not possible to resolve
host to deliver these hints. We are not doing anything with that exception. I
mean ... throwing an exception _is fine_ it is just that I would expect we
catch it later and just log an error, no? Why do you want to have an exception
in the logs instead of an error log? Logging it on ERROR is just completely
fine. I just do not want to see the stacktrace. That is irrelevant for a user.
If you want that method still throw an exception, for whatever reason, alright,
I just do not see why it would need to be logged like that. There is nobody who
is reacting on this exception, we just propagate it up and that's it.
I change the implementation to show you what I meant by that here:
[https://github.com/apache/cassandra/pull/4775/changes]
> Decommission fails with "Unable to stream hints since no live endpoints seen"
> even if no hints need to be sent
> --------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-15437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15437
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
> Reporter: YCozy
> Assignee: Stefan Miklosovic
> Priority: Normal
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Dear Cassandra developers, I was applying fault-injection to test Cassandra
> and noticed the following behavior. I think this may be a bug. Please let me
> know if I'm missing something.
>
> Step to reproduce:
> # Start a two node cluster (node1 & node2) using {{ccm}}.
> # Add another node to the cluster (node3).
> # Partition node3 from the other two nodes.
> # Try to decommission node3 using {{nodetool decommission}}.
> # Notice that the decommission failed with the following error log:
>
> {code:java}
> ERROR [RMI TCP Connection(4)-127.0.0.1] 2019-11-25 22:45:27,716
> StorageService.java:4198 - Error while decommissioning node
> java.lang.RuntimeException: Unable to stream hints since no live endpoints
> seen
> at
> org.apache.cassandra.service.StorageService.getPreferredHintsStreamTarget(StorageService.java:4281)
> at
> org.apache.cassandra.hints.HintsDispatchExecutor$TransferHintsTask.run(HintsDispatchExecutor.java:156)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748){code}
>
> Since I didn't write any data, there is no hint to be sent. In this case,
> shouldn't the decommission continue?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
