[jira] [Commented] (CASSANDRA-7950) Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names.
[
https://issues.apache.org/jira/browse/CASSANDRA-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730579#comment-14730579
]
Eugene commented on CASSANDRA-7950:
---
Thank you to everyone that has worked on this so far.
Will this, by chance, also fix the output of other commands, for example
`nodetool listsnapshots`?
I created a snapshot with a long tag
(some-really-long-snapshot-name-geezey-petes). Ended up with the following:
{code}
# nodetool listsnapshots
Snapshot Details:
Snapshot name Keyspace nameColumn family name
True size Size on disk
some-really-long-snapshot-name-geezey-petesgalactaron
replicatorstide 0 bytes570.68 MB
some-really-long-snapshot-name-geezey-petesdse_system leases
0 bytes13 bytes
some-really-long-snapshot-name-geezey-petesdse_system
real_leaders 0 bytes13 bytes
some-really-long-snapshot-name-geezey-petesdse_system
encrypted_keys 0 bytes13 bytes
some-really-long-snapshot-name-geezey-petesdse_system
registered_leaders 0 bytes13 bytes
{code}
> Output of nodetool compactionstats and compactionhistory does not work well
> with long keyspace and column family names.
> -
>
> Key: CASSANDRA-7950
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7950
> Project: Cassandra
> Issue Type: Bug
> Environment: CentOS 5, 64bit, Oracle JDK 7, DSE
>Reporter: Eugene
>Assignee: Michael Shuler
>Priority: Minor
> Labels: lhf
> Fix For: 2.1.x
>
> Attachments: 7950.patch, nodetool-examples.txt
>
>
> When running these commands:
> nodetool compactionstats
> nodetool compactionhistory
> The output can be difficult to grok due to long keyspace names, column family
> names, and long values. I have attached an example.
> It's difficult for both humans and grep/sed/awk/perl to read.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9064) [LeveledCompactionStrategy] cqlsh can't run cql produced by its own describe table statement
[
https://issues.apache.org/jira/browse/CASSANDRA-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14592777#comment-14592777
]
Eugene commented on CASSANDRA-9064:
---
It would be nice to get this fixed.
For anyone looking for a work around, just strip out the min_threshold and
max_threshold fields on the describe keyspace output.
This might work in some situations:
{code} sed -i -e s/{.*LeveledCompactionStrategy.*}/{'class':
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}/ tables.txt
{code}
Before using that verify that the compaction configuration for those tables
don't have anything other than *min_threshold*, *max_threshold*, and *class*
parameters defined.
[LeveledCompactionStrategy] cqlsh can't run cql produced by its own describe
table statement
Key: CASSANDRA-9064
URL: https://issues.apache.org/jira/browse/CASSANDRA-9064
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: cassandra 2.1.3 on mac os x
Reporter: Sujeet Gholap
Assignee: Benjamin Lerer
Labels: cqlsh
Fix For: 2.1.x
Here's how to reproduce:
1) Create a table with LeveledCompactionStrategy
CREATE keyspace foo WITH REPLICATION = {'class': 'SimpleStrategy',
'replication_factor' : 3};
CREATE TABLE foo.bar (
spam text PRIMARY KEY
) WITH compaction = {'class': 'LeveledCompactionStrategy'};
2) Describe the table and save the output
cqlsh -e describe table foo.bar
Output should be something like
CREATE TABLE foo.bar (
spam text PRIMARY KEY
) WITH bloom_filter_fp_chance = 0.1
AND caching = '{keys:ALL, rows_per_partition:NONE}'
AND comment = ''
AND compaction = {'min_threshold': '4', 'class':
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy',
'max_threshold': '32'}
AND compression = {'sstable_compression':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99.0PERCENTILE';
3) Save the output to repro.cql
4) Drop the table foo.bar
cqlsh -e drop table foo.bar
5) Run the create table statement we saved
cqlsh -f repro.cql
6) Expected: normal execution without an error
7) Reality:
ConfigurationException: ErrorMessage code=2300 [Query invalid because of
configuration issue] message=Properties specified [min_threshold,
max_threshold] are not understood by LeveledCompactionStrategy
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-7950) Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names.
[ https://issues.apache.org/jira/browse/CASSANDRA-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14284206#comment-14284206 ] Eugene edited comment on CASSANDRA-7950 at 1/20/15 6:57 PM: Might be worth looking into how the column command does it. e.g.: cat /proc/meminfo cat /proc/meminfo | column -t At the very least if these nodetool commands had proper delimitation (e.g. at least a single space between fields) their output could be easily parsed by utilities and the column command could be used manually to correct the output. was (Author: aechttpd): Might be worth looking into how the column command does it. e.g.: cat /proc/meminfo cat /proc/meminfo | column -t At the very least if these nodetool commands had proper delimitation (a single space between fields) their output could be easily parsed by utilities and the column command could be used manually to correct the output. Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names. - Key: CASSANDRA-7950 URL: https://issues.apache.org/jira/browse/CASSANDRA-7950 Project: Cassandra Issue Type: Bug Environment: CentOS 5, 64bit, Oracle JDK 7, DSE Reporter: Eugene Priority: Minor Labels: lhf Fix For: 2.0.13 Attachments: nodetool-examples.txt When running these commands: nodetool compactionstats nodetool compactionhistory The output can be difficult to grok due to long keyspace names, column family names, and long values. I have attached an example. It's difficult for both humans and grep/sed/awk/perl to read. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7950) Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names.
[ https://issues.apache.org/jira/browse/CASSANDRA-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14284206#comment-14284206 ] Eugene commented on CASSANDRA-7950: --- Might be worth looking into how the column command does it. e.g.: cat /proc/meminfo cat /proc/meminfo | column -t At the very least if these nodetool commands had proper delimitation (a single space between fields) their output could be easily parsed by utilities and the column command could be used manually to correct the output. Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names. - Key: CASSANDRA-7950 URL: https://issues.apache.org/jira/browse/CASSANDRA-7950 Project: Cassandra Issue Type: Bug Environment: CentOS 5, 64bit, Oracle JDK 7, DSE Reporter: Eugene Priority: Minor Labels: lhf Fix For: 2.0.13 Attachments: nodetool-examples.txt When running these commands: nodetool compactionstats nodetool compactionhistory The output can be difficult to grok due to long keyspace names, column family names, and long values. I have attached an example. It's difficult for both humans and grep/sed/awk/perl to read. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-7950) Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names.
Eugene created CASSANDRA-7950: - Summary: Output of nodetool compactionstats and compactionhistory does not work well with long keyspace and column family names. Key: CASSANDRA-7950 URL: https://issues.apache.org/jira/browse/CASSANDRA-7950 Project: Cassandra Issue Type: Bug Environment: CentOS 5, 64bit, Oracle JDK 7, DSE Reporter: Eugene Priority: Minor Fix For: 2.0.6 Attachments: nodetool-examples.txt When running these commands: nodetool compactionstats nodetool compactionhistory The output can be difficult to grok due to long keyspace names, column family names, and long values. I have attached an example. It's difficult for both humans and grep/sed/awk/perl to read. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-3512) Getting Started instructions don't work in README.txt - wrong version of jamm, wrong path
[
https://issues.apache.org/jira/browse/CASSANDRA-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13616636#comment-13616636
]
Eugene commented on CASSANDRA-3512:
---
I had this error under CentOS 5 using the RPM packages provided by DataStax.
The issue for me was '/etc/cassandra/conf/cassandra-env.sh' called jamm using
the following:
{noformat}
cassandra-env.sh:JVM_OPTS=$JVM_OPTS
-javaagent:$CASSANDRA_HOME/lib/jamm-0.2.5.jar
{noformat}
However, $CASSANDRA_HOME isn't set anywhere.
I fixed it by adding the following to '/usr/share/cassandra/cassandra.in.sh':
{noformat}
CASSANDRA_HOME=/usr/share/cassandra
{noformat}
Getting Started instructions don't work in README.txt - wrong version of
jamm, wrong path
-
Key: CASSANDRA-3512
URL: https://issues.apache.org/jira/browse/CASSANDRA-3512
Project: Cassandra
Issue Type: Bug
Components: Packaging
Environment: Ubuntu 11.04
Reporter: David Allsopp
Assignee: Brandon Williams
Priority: Minor
Fix For: 2.0
Download latest release from
http://www.apache.org/dyn/closer.cgi?path=/cassandra/1.0.3/apache-cassandra-1.0.3-bin.tar.gz
Unpack the tarball.
Follow instructions in README.txt, concluding with:
{noformat}
dna@master:~/code/apache-cassandra-1.0.3$ bin/cassandra -f
Error opening zip file or JAR manifest missing : /lib/jamm-0.2.1.jar
Error occurred during initialization of VM
agent library failed to init: instrument
{noformat}
Firstly, the version of jamm packaged with Cassandra 1.0.3 is jamm-0.2.5, not
jamm-0.2.1.
Both bin/cassandra.bat and conf/cassandra-env.sh reference jamm-0.2.5 so not
sure where jamm-0.2.1 is being referenced from - nothing obvious using grep.
Secondly, /lib/jamm-0.2.1.jar is the wrong path - should be set relative to
working directory, not filesystem root
(Incidentally, Cassandra v1.0.3 is still listed as unreleased on JIRA.)
--
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] [Comment Edited] (CASSANDRA-3512) Getting Started instructions don't work in README.txt - wrong version of jamm, wrong path
[
https://issues.apache.org/jira/browse/CASSANDRA-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13616636#comment-13616636
]
Eugene edited comment on CASSANDRA-3512 at 3/28/13 8:53 PM:
I had this error under CentOS 5 using the RPM packages provided by DataStax.
The issue for me was '/etc/cassandra/conf/cassandra-env.sh' called jamm using
the following:
{noformat}
cassandra-env.sh:JVM_OPTS=$JVM_OPTS
-javaagent:$CASSANDRA_HOME/lib/jamm-0.2.5.jar
{noformat}
However, $CASSANDRA_HOME isn't set anywhere.
I fixed it by adding the following to '/usr/share/cassandra/cassandra.in.sh':
{noformat}
CASSANDRA_HOME=/usr/share/cassandra
{noformat}
was (Author: aechttpd):
I had this error under CentOS 5 using the RPM packages provided by
DataStax. The issue for me was '/etc/cassandra/conf/cassandra-env.sh' called
jamm using the following:
{noformat}
cassandra-env.sh:JVM_OPTS=$JVM_OPTS
-javaagent:$CASSANDRA_HOME/lib/jamm-0.2.5.jar
{noformat}
However, $CASSANDRA_HOME isn't set anywhere.
I fixed it by adding the following to '/usr/share/cassandra/cassandra.in.sh':
{noformat}
CASSANDRA_HOME=/usr/share/cassandra
{noformat}
Getting Started instructions don't work in README.txt - wrong version of
jamm, wrong path
-
Key: CASSANDRA-3512
URL: https://issues.apache.org/jira/browse/CASSANDRA-3512
Project: Cassandra
Issue Type: Bug
Components: Packaging
Environment: Ubuntu 11.04
Reporter: David Allsopp
Assignee: Brandon Williams
Priority: Minor
Fix For: 2.0
Download latest release from
http://www.apache.org/dyn/closer.cgi?path=/cassandra/1.0.3/apache-cassandra-1.0.3-bin.tar.gz
Unpack the tarball.
Follow instructions in README.txt, concluding with:
{noformat}
dna@master:~/code/apache-cassandra-1.0.3$ bin/cassandra -f
Error opening zip file or JAR manifest missing : /lib/jamm-0.2.1.jar
Error occurred during initialization of VM
agent library failed to init: instrument
{noformat}
Firstly, the version of jamm packaged with Cassandra 1.0.3 is jamm-0.2.5, not
jamm-0.2.1.
Both bin/cassandra.bat and conf/cassandra-env.sh reference jamm-0.2.5 so not
sure where jamm-0.2.1 is being referenced from - nothing obvious using grep.
Secondly, /lib/jamm-0.2.1.jar is the wrong path - should be set relative to
working directory, not filesystem root
(Incidentally, Cassandra v1.0.3 is still listed as unreleased on JIRA.)
--
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
