cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kirk True (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6397) removenode outputs confusing non-error
Date Tue, 20 May 2014 16:58:39 GMT


Kirk True commented on CASSANDRA-6397:

Yes, I agree that's ugly.

My concern is that this change turns an error case (forcing when nothing is being removed)
into a non-error case. Do users of either nodetool or JMX rely on getting an error? Do they
need to know that their request was a no-op when they ask to force a removenode?

If so, they can check the boolean, kind of like File.delete(). But if you want, I can just
remove the boolean FYI flag altogether.

> removenode outputs confusing non-error
> --------------------------------------
>                 Key: CASSANDRA-6397
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Tools
>            Reporter: Ryan McGuire
>            Assignee: Kirk True
>            Priority: Trivial
>              Labels: lhf
>             Fix For: 2.0.8
>         Attachments: trunk-6397.txt
> *{{nodetool removenode force}}* outputs a slightly confusing error message when there
is nothing for it to do.
> * Start a cluster, then kill one of the nodes.
> * run *{{nodetool removenode}}* on the node you killed.
> * Simultaneously, in another shell, run *{{nodetool removenode force}}*, see that it
outputs a simple message regarding it's status.
> * Run *{{nodetool removenode force}}* again after the firsrt removenode command finishes,
you'll see this message and traceback:
> {code}
> $ ~/.ccm/test/node1/bin/nodetool -p 7100 removenode force
> RemovalStatus: No token removals in process.
> Exception in thread "main" java.lang.UnsupportedOperationException: No tokens to force
removal on, call 'removetoken' first
> 	at org.apache.cassandra.service.StorageService.forceRemoveCompletion(
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> 	at java.lang.reflect.Method.invoke(
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(
> 	at
> 	at$300(
> 	at$
> 	at
> 	at
> 	at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> 	at java.lang.reflect.Method.invoke(
> 	at sun.rmi.server.UnicastServerRef.dispatch(
> 	at sun.rmi.transport.Transport$
> 	at sun.rmi.transport.Transport$
> 	at Method)
> 	at sun.rmi.transport.Transport.serviceCall(
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(
> 	at sun.rmi.transport.tcp.TCPTransport$
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(
> 	at java.util.concurrent.ThreadPoolExecutor$
> 	at
> {code}
> Two issues I see with this traceback:
> * "No tokens to force removal on" is telling me the same thing that the message before
it tells me: "RemovalStatus: No token removals in process.", So the entire traceback is redundant.
> * "call 'removetoken' first" - removetoken has been deprecated according to the message
output by removenode, so there is inconsistency in directions to the user.

This message was sent by Atlassian JIRA

View raw message