cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward Capriolo (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-11537) Give clear error when certain nodetool commands are issued before server is ready
Date Mon, 18 Apr 2016 14:13:25 GMT

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

Edward Capriolo commented on CASSANDRA-11537:
---------------------------------------------

All points well taken with the startupDone flag. 

I *think* the user wants the stack trace. IE if my job is to script a cluster wide compaction
using nodetool, the 'compact' command should let me know that this failed. The best is likely
the non 0 result and message bubble all the way out to the user.

For example in this case. Imagine if you are going to perform an upgrade/scrub on all nodes
after upgrading your cassandra version. If you trigger the command early and there is no error
return. This could lead you to wrongfully assume the data files are upgraded. You want to
know if the command failed or not.



> Give clear error when certain nodetool commands are issued before server is ready
> ---------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-11537
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11537
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Edward Capriolo
>            Assignee: Edward Capriolo
>            Priority: Minor
>              Labels: lhf
>
> As an ops person upgrading and servicing Cassandra servers, I require a more clear message
when I issue a nodetool command that the server is not ready for it so that I am not confused.
> Technical description:
> If you deploy a new binary, restart, and issue nodetool scrub/compact/updatess etc you
get unfriendly assertion. An exception would be easier to understand. Also if a user has turned
assertions off it is unclear what might happen. 
> {noformat}
> EC1: Throw exception to make it clear server is still in start up process. 
> :~# nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.AssertionError
>     at org.apache.cassandra.db.Keyspace.open(Keyspace.java:97)
>     at org.apache.cassandra.service.StorageService.getValidKeyspace(StorageService.java:2573)
>     at org.apache.cassandra.service.StorageService.getValidColumnFamilies(StorageService.java:2661)
>     at org.apache.cassandra.service.StorageService.upgradeSSTables(StorageService.java:2421)
> {noformat}
> EC1: 
> Patch against 2.1 (branch)
> https://github.com/apache/cassandra/compare/trunk...edwardcapriolo:exception-on-startup?expand=1



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message