[jira] [Commented] (CASSANDRA-5860) Don't print CQL related omission warning in CLI
[ https://issues.apache.org/jira/browse/CASSANDRA-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13733154#comment-13733154 ] Manoj Mainali commented on CASSANDRA-5860: -- Please ignore my above comments. > Don't print CQL related omission warning in CLI > --- > > Key: CASSANDRA-5860 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5860 > Project: Cassandra > Issue Type: Improvement >Reporter: Manoj Mainali >Assignee: Manoj Mainali >Priority: Trivial > Attachments: trunk-CASSANDRA-5860.patch > > > Due to CASSANDRA-4377, a warning message was printed in CLI for show > keyspaces, schema or describe CF. But since now CLI can show CQL3 tables and > CASSANDRA-4377 is already fixed, this warning message would not be required > anymore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5860) Don't print CQL related omission warning in CLI
[ https://issues.apache.org/jira/browse/CASSANDRA-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13733121#comment-13733121 ] Manoj Mainali commented on CASSANDRA-5860: -- Sorry not. I saw the keyspaces, so assumed it was able to show CF's too. I will mark this as invalid. On a side note, if we say the cause was CASSANDRA-4377 and it is fixed, wouldn't it be possible to show the CQL tables? > Don't print CQL related omission warning in CLI > --- > > Key: CASSANDRA-5860 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5860 > Project: Cassandra > Issue Type: Improvement >Reporter: Manoj Mainali >Assignee: Manoj Mainali >Priority: Trivial > Attachments: trunk-CASSANDRA-5860.patch > > > Due to CASSANDRA-4377, a warning message was printed in CLI for show > keyspaces, schema or describe CF. But since now CLI can show CQL3 tables and > CASSANDRA-4377 is already fixed, this warning message would not be required > anymore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5860) Don't print CQL related omission warning in CLI
Manoj Mainali created CASSANDRA-5860: Summary: Don't print CQL related omission warning in CLI Key: CASSANDRA-5860 URL: https://issues.apache.org/jira/browse/CASSANDRA-5860 Project: Cassandra Issue Type: Improvement Reporter: Manoj Mainali Assignee: Manoj Mainali Priority: Trivial Attachments: trunk-CASSANDRA-5860.patch Due to CASSANDRA-4377, a warning message was printed in CLI for show keyspaces, schema or describe CF. But since now CLI can show CQL3 tables and CASSANDRA-4377 is already fixed, this warning message would not be required anymore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5860) Don't print CQL related omission warning in CLI
[ https://issues.apache.org/jira/browse/CASSANDRA-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manoj Mainali updated CASSANDRA-5860: - Attachment: trunk-CASSANDRA-5860.patch Attaching the patch > Don't print CQL related omission warning in CLI > --- > > Key: CASSANDRA-5860 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5860 > Project: Cassandra > Issue Type: Improvement >Reporter: Manoj Mainali >Assignee: Manoj Mainali >Priority: Trivial > Attachments: trunk-CASSANDRA-5860.patch > > > Due to CASSANDRA-4377, a warning message was printed in CLI for show > keyspaces, schema or describe CF. But since now CLI can show CQL3 tables and > CASSANDRA-4377 is already fixed, this warning message would not be required > anymore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5827) Expose setters for consistency level in Hadoop config helper
Manoj Mainali created CASSANDRA-5827: Summary: Expose setters for consistency level in Hadoop config helper Key: CASSANDRA-5827 URL: https://issues.apache.org/jira/browse/CASSANDRA-5827 Project: Cassandra Issue Type: Bug Reporter: Manoj Mainali Assignee: Manoj Mainali Priority: Minor Attachments: trunk-CASSANDRA-5827.patch ConfigHelper exposes the getters for read and write consistency, which defaults to the consistency level of "ONE" if one is not defined. However, setters are missing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5827) Expose setters for consistency level in Hadoop config helper
[ https://issues.apache.org/jira/browse/CASSANDRA-5827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manoj Mainali updated CASSANDRA-5827: - Attachment: trunk-CASSANDRA-5827.patch Attaching the patch > Expose setters for consistency level in Hadoop config helper > > > Key: CASSANDRA-5827 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5827 > Project: Cassandra > Issue Type: Bug >Reporter: Manoj Mainali >Assignee: Manoj Mainali >Priority: Minor > Attachments: trunk-CASSANDRA-5827.patch > > > ConfigHelper exposes the getters for read and write consistency, which > defaults to the consistency level of "ONE" if one is not defined. However, > setters are missing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5776) Print nodetool commands in sorted order
[
https://issues.apache.org/jira/browse/CASSANDRA-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13716039#comment-13716039
]
Manoj Mainali commented on CASSANDRA-5776:
--
Thanks. I didn't notice the format of first "{" was off.
> Print nodetool commands in sorted order
> ---
>
> Key: CASSANDRA-5776
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5776
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Affects Versions: 1.2.6
>Reporter: Manoj Mainali
>Assignee: Manoj Mainali
>Priority: Minor
> Fix For: 1.2.7
>
> Attachments: trunk-CASSANDRA-5776.patch
>
>
> nodetool commands are printed in the unsorted order (they are printed in the
> order they are written in the NodeToolHelp.yaml file). At the moment, the
> same/related commands are grouped together and the it is also nicely
> formated. But, since it is unsorted it is hard to find the command especially
> when looking for the options for the command, if you already know the command
> name.
> Wouldn't it be better to print the commands in sorted order?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5776) Print nodetool commands in sorted order
[ https://issues.apache.org/jira/browse/CASSANDRA-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manoj Mainali updated CASSANDRA-5776: - Attachment: trunk-CASSANDRA-5776.patch > Print nodetool commands in sorted order > --- > > Key: CASSANDRA-5776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5776 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Affects Versions: 1.2.6 >Reporter: Manoj Mainali >Priority: Minor > Attachments: trunk-CASSANDRA-5776.patch > > > nodetool commands are printed in the unsorted order (they are printed in the > order they are written in the NodeToolHelp.yaml file). At the moment, the > same/related commands are grouped together and the it is also nicely > formated. But, since it is unsorted it is hard to find the command especially > when looking for the options for the command, if you already know the command > name. > Wouldn't it be better to print the commands in sorted order? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5776) Print nodetool commands in sorted order
Manoj Mainali created CASSANDRA-5776: Summary: Print nodetool commands in sorted order Key: CASSANDRA-5776 URL: https://issues.apache.org/jira/browse/CASSANDRA-5776 Project: Cassandra Issue Type: Improvement Components: Tools Affects Versions: 1.2.6 Reporter: Manoj Mainali Priority: Minor nodetool commands are printed in the unsorted order (they are printed in the order they are written in the NodeToolHelp.yaml file). At the moment, the same/related commands are grouped together and the it is also nicely formated. But, since it is unsorted it is hard to find the command especially when looking for the options for the command, if you already know the command name. Wouldn't it be better to print the commands in sorted order? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5734) Print usage when command is not specified in nodetool instead of connection failure
[
https://issues.apache.org/jira/browse/CASSANDRA-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manoj Mainali updated CASSANDRA-5734:
-
Attachment: trunk-CASSANDRA-5734-v1.patch
Changed the tabs to spaces. Hope this time formatting is right.
> Print usage when command is not specified in nodetool instead of connection
> failure
> ---
>
> Key: CASSANDRA-5734
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5734
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Affects Versions: 1.2.6
>Reporter: Manoj Mainali
>Assignee: Manoj Mainali
>Priority: Minor
> Fix For: 1.2.7
>
> Attachments: trunk-CASSANDRA-5734.patch, trunk-CASSANDRA-5734-v1.patch
>
>
> nodetool command tries to establish connection to the cassandra node before
> ensuring that the command is valid. Therefore, when no command is specified
> it will print (in the case when C* is not running)
> {noformat}
> $ bin/nodetool
> Failed to connect to '127.0.0.1:7199': Connection refused
> {noformat}
> That means we need to have a running instance of C* to check the available
> commands. But this is a syntax error and usage can be displayed (which is the
> result even if a C* is running) even without a C* instance. Probably, it
> would be better to make sure that the command sytnax is valid and print usage
> if not. By doing this, we can easily check the available commands.
> Additionally, same should apply for the help command. Since, help will not be
> connecting to the C* instance, we should not have a dependency on a running
> C*.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5734) Print usage when command is not specified in nodetool instead of connection failure
[
https://issues.apache.org/jira/browse/CASSANDRA-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manoj Mainali updated CASSANDRA-5734:
-
Description:
nodetool command tries to establish connection to the cassandra node before
ensuring that the command is valid. Therefore, when no command is specified it
will print (in the case when C* is not running)
{noformat}
$ bin/nodetool
Failed to connect to '127.0.0.1:7199': Connection refused
{noformat}
That means we need to have a running instance of C* to check the available
commands. But this is a syntax error and usage can be displayed (which is the
result even if a C* is running) even without a C* instance. Probably, it would
be better to make sure that the command sytnax is valid and print usage if not.
By doing this, we can easily check the available commands.
Additionally, same should apply for the help command. Since, help will not be
connecting to the C* instance, we should not have a dependency on a running C*.
was:
nodetool command tries to establish connection to the cassandra node before
ensuring that the command is valid. Therefore, when no command is specified it
will print
{noformat}
$ bin/nodetool
Failed to connect to '127.0.0.1:7199': Connection refused
{noformat}
That means we need to have a running instance of C* to check the available
commands. But this is a syntax error and usage can be displayed (which is the
result even if a C* is running) even without a C* instance. Probably, it would
be better to make sure that the command sytnax is valid and print usage if not.
By doing this, we can easily check the available commands.
Additionally, same should apply for the help command. Since, help will not be
connecting to the C* instance, we should not have a dependency on a running C*.
> Print usage when command is not specified in nodetool instead of connection
> failure
> ---
>
> Key: CASSANDRA-5734
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5734
> Project: Cassandra
> Issue Type: Improvement
>Affects Versions: 1.2.6
>Reporter: Manoj Mainali
>Priority: Minor
> Attachments: trunk-CASSANDRA-5734.patch
>
>
> nodetool command tries to establish connection to the cassandra node before
> ensuring that the command is valid. Therefore, when no command is specified
> it will print (in the case when C* is not running)
> {noformat}
> $ bin/nodetool
> Failed to connect to '127.0.0.1:7199': Connection refused
> {noformat}
> That means we need to have a running instance of C* to check the available
> commands. But this is a syntax error and usage can be displayed (which is the
> result even if a C* is running) even without a C* instance. Probably, it
> would be better to make sure that the command sytnax is valid and print usage
> if not. By doing this, we can easily check the available commands.
> Additionally, same should apply for the help command. Since, help will not be
> connecting to the C* instance, we should not have a dependency on a running
> C*.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5735) Add binary server status to the node information
[ https://issues.apache.org/jira/browse/CASSANDRA-5735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manoj Mainali updated CASSANDRA-5735: - Attachment: trunk-CASSANDRA-5735.patch > Add binary server status to the node information > > > Key: CASSANDRA-5735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5735 > Project: Cassandra > Issue Type: Improvement >Affects Versions: 1.2.6 >Reporter: Manoj Mainali >Priority: Minor > Attachments: trunk-CASSANDRA-5735.patch > > > nodetool info gives the gossip and thrift active status. Now, since there is > a binary server it is nice to have the binary status too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5735) Add binary server status to the node information
Manoj Mainali created CASSANDRA-5735: Summary: Add binary server status to the node information Key: CASSANDRA-5735 URL: https://issues.apache.org/jira/browse/CASSANDRA-5735 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2.6 Reporter: Manoj Mainali Priority: Minor nodetool info gives the gossip and thrift active status. Now, since there is a binary server it is nice to have the binary status too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5734) Print usage when command is not specified in nodetool instead of connection failure
[
https://issues.apache.org/jira/browse/CASSANDRA-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manoj Mainali updated CASSANDRA-5734:
-
Attachment: trunk-CASSANDRA-5734.patch
> Print usage when command is not specified in nodetool instead of connection
> failure
> ---
>
> Key: CASSANDRA-5734
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5734
> Project: Cassandra
> Issue Type: Improvement
>Affects Versions: 1.2.6
>Reporter: Manoj Mainali
>Priority: Minor
> Attachments: trunk-CASSANDRA-5734.patch
>
>
> nodetool command tries to establish connection to the cassandra node before
> ensuring that the command is valid. Therefore, when no command is specified
> it will print
> {noformat}
> $ bin/nodetool
> Failed to connect to '127.0.0.1:7199': Connection refused
> {noformat}
> That means we need to have a running instance of C* to check the available
> commands. But this is a syntax error and usage can be displayed (which is the
> result even if a C* is running) even without a C* instance. Probably, it
> would be better to make sure that the command sytnax is valid and print usage
> if not. By doing this, we can easily check the available commands.
> Additionally, same should apply for the help command. Since, help will not be
> connecting to the C* instance, we should not have a dependency on a running
> C*.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5734) Print usage when command is not specified in nodetool instead of connection failure
Manoj Mainali created CASSANDRA-5734:
Summary: Print usage when command is not specified in nodetool
instead of connection failure
Key: CASSANDRA-5734
URL: https://issues.apache.org/jira/browse/CASSANDRA-5734
Project: Cassandra
Issue Type: Improvement
Affects Versions: 1.2.6
Reporter: Manoj Mainali
Priority: Minor
nodetool command tries to establish connection to the cassandra node before
ensuring that the command is valid. Therefore, when no command is specified it
will print
{noformat}
$ bin/nodetool
Failed to connect to '127.0.0.1:7199': Connection refused
{noformat}
That means we need to have a running instance of C* to check the available
commands. But this is a syntax error and usage can be displayed (which is the
result even if a C* is running) even without a C* instance. Probably, it would
be better to make sure that the command sytnax is valid and print usage if not.
By doing this, we can easily check the available commands.
Additionally, same should apply for the help command. Since, help will not be
connecting to the C* instance, we should not have a dependency on a running C*.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
