cassandra-commits mailing list archives

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

    [ https://issues.apache.org/jira/browse/CASSANDRA-6397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14003629#comment-14003629
] 

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: https://issues.apache.org/jira/browse/CASSANDRA-6397
>             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(StorageService.java:3140)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:250)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791)
> 	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1486)
> 	at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:96)
> 	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1327)
> 	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1419)
> 	at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:847)
> 	at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:177)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:174)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:722)
> {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
(v6.2#6252)

Mime
View raw message