[jira] [Updated] (CASSANDRA-15806) C* 4.0 is missing a way to identify transient/non-transient SSTables on disk
[
https://issues.apache.org/jira/browse/CASSANDRA-15806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
sequoyha pelletier updated CASSANDRA-15806:
---
Test and Documentation Plan:
Ran a simple test against sstable to make sure it worked:
{noformat}
sequoyha.pelletier@spelletier-rmbp15:[~/cassandra-trunk/tools/bin]
510-Mon May 11 15:16
LocalDeletionTime: 144288 (09/21/2015 17:00:00)
EncodingStats minTimestamp: 1588980982231688 (05/08/2020 16:36:22)
...
RegularColumns: author:org.apache.cassandra.db.marshal.UTF8Type,
isbn:org.apache.cassandra.db.marshal.UTF8Type,
publisher:org.apache.cassandra.db.marshal.UTF8Type,
category:org.apache.cassandra.db.marshal.UTF8Type,
product_name:org.apache.cassandra.db.marshal.UTF8Type
Is Transient: false{noformat}
The isTransient is a boolean value so false is enough to verify the information
is showing.
was:
Tested agains sstables to make sure it worked:
{noformat}
sequoyha.pelletier@spelletier-rmbp15:[~/cassandra-trunk/tools/bin]
510-Mon May 11 15:16
-->$ ./sstablemetadata
../../data/data/daintree/products-2080916511eab425f9ae993c7b2c/na-7-big-Statistics.db
SSTable:
/Users/sequoyha.pelletier/cassandra-trunk/data/data/daintree/products-2080916511eab425f9ae993c7b2c/na-7-big
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Bloom Filter FP chance: 0.01
Minimum timestamp: 1588980982231688 (05/08/2020 16:36:22)
Maximum timestamp: 1588982281330936 (05/08/2020 16:58:01)
SSTable min local deletion time: 2147483647 (no tombstones)
SSTable max local deletion time: 2147483647 (no tombstones)
Compressor: org.apache.cassandra.io.compress.LZ4Compressor
Compression ratio: 0.6960054067248149
TTL min: 0
TTL max: 0
First token: -9223366104813810737 (cac75b42-a598-4d11-b497-80ffd39da575)
Last token: 9223335123199673029 (21dd4443-55b8-4592-a3f5-d76e9e35014e)
minClusteringValues: []
maxClusteringValues: []
Estimated droppable tombstones: 0.0
SSTable Level: 0
Repaired at: 0
Pending repair: --
Replay positions covered: {CommitLogPosition(segmentId=1588977222779,
position=494)=CommitLogPosition(segmentId=1588977222788, position=10467779),
CommitLogPosition(segmentId=1589235043721,
position=494)=CommitLogPosition(segmentId=1589235043721, position=494)}
totalColumnsSet: 5242880
totalRows: 1048576
Estimated tombstone drop times:
Drop Time | Count (%) Histogram
Percentiles
50th 0
75th 0
95th 0
98th 0
99th 0
Min 0
Max 0
Partition Size:
Size (bytes) | Count (%) Histogram
103 (103 B) | 27198 ( 2) O
124 (124 B) | 663446 ( 63) OO
149 (149 B) | 347860 ( 33) OOO.
179 (179 B) | 10061 ( 0) .
215 (215 B) | 11 ( 0)
Percentiles
50th 124 (124 B)
75th 149 (149 B)
95th 149 (149 B)
98th 149 (149 B)
99th 149 (149 B)
Min 87 (87 B)
Max 215 (215 B)
Column Count:
Columns | Count (%) Histogram
5 | 1048576 (100) OO
Percentiles
50th 5
75th 5
95th 5
98th 5
99th 5
Min 5
Max 5
Estimated cardinality: 1029815
EncodingStats minTTL: 0
EncodingStats minLocalDeletionTime: 144288 (09/21/2015 17:00:00)
EncodingStats minTimestamp: 1588980982231688 (05/08/2020 16:36:22)
KeyType: org.apache.cassandra.db.marshal.UUIDType
ClusteringTypes: []
StaticColumns:
RegularColumns: author:org.apache.cassandra.db.marshal.UTF8Type,
isbn:org.apache.cassandra.db.marshal.UTF8Type,
publisher:org.apache.cassandra.db.marshal.UTF8Type,
category:org.apache.cassandra.db.marshal.UTF8Type,
product_name:org.apache.cassandra.db.marshal.UTF8Type
Is Transient: false{noformat}
> C* 4.0 is missing a way to identify transient/non-transient SSTables on disk
>
>
> Key: CASSANDRA-15806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15806
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: sequoyha pelletier
>Assignee: sequoyha pelletier
>Priority: Normal
> Fix For: 4.0
>
> Attachments: 15806-4.0.txt
>
>
> Currently, there is no way to identify SSTables that were created as
> transient replicated data. Even thought the feature is experimental we should
> open that up for those that want to experiment. This seems to be an
> oversight. I have added the missing line of code to the SStableMetadataViewer
> and will attach a patch shortly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15806) C* 4.0 is missing a way to identify transient SSTables on disk
[
https://issues.apache.org/jira/browse/CASSANDRA-15806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
sequoyha pelletier updated CASSANDRA-15806:
---
Test and Documentation Plan:
Tested agains sstables to make sure it worked:
{noformat}
sequoyha.pelletier@spelletier-rmbp15:[~/cassandra-trunk/tools/bin]
510-Mon May 11 15:16
-->$ ./sstablemetadata
../../data/data/daintree/products-2080916511eab425f9ae993c7b2c/na-7-big-Statistics.db
SSTable:
/Users/sequoyha.pelletier/cassandra-trunk/data/data/daintree/products-2080916511eab425f9ae993c7b2c/na-7-big
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Bloom Filter FP chance: 0.01
Minimum timestamp: 1588980982231688 (05/08/2020 16:36:22)
Maximum timestamp: 1588982281330936 (05/08/2020 16:58:01)
SSTable min local deletion time: 2147483647 (no tombstones)
SSTable max local deletion time: 2147483647 (no tombstones)
Compressor: org.apache.cassandra.io.compress.LZ4Compressor
Compression ratio: 0.6960054067248149
TTL min: 0
TTL max: 0
First token: -9223366104813810737 (cac75b42-a598-4d11-b497-80ffd39da575)
Last token: 9223335123199673029 (21dd4443-55b8-4592-a3f5-d76e9e35014e)
minClusteringValues: []
maxClusteringValues: []
Estimated droppable tombstones: 0.0
SSTable Level: 0
Repaired at: 0
Pending repair: --
Replay positions covered: {CommitLogPosition(segmentId=1588977222779,
position=494)=CommitLogPosition(segmentId=1588977222788, position=10467779),
CommitLogPosition(segmentId=1589235043721,
position=494)=CommitLogPosition(segmentId=1589235043721, position=494)}
totalColumnsSet: 5242880
totalRows: 1048576
Estimated tombstone drop times:
Drop Time | Count (%) Histogram
Percentiles
50th 0
75th 0
95th 0
98th 0
99th 0
Min 0
Max 0
Partition Size:
Size (bytes) | Count (%) Histogram
103 (103 B) | 27198 ( 2) O
124 (124 B) | 663446 ( 63) OO
149 (149 B) | 347860 ( 33) OOO.
179 (179 B) | 10061 ( 0) .
215 (215 B) | 11 ( 0)
Percentiles
50th 124 (124 B)
75th 149 (149 B)
95th 149 (149 B)
98th 149 (149 B)
99th 149 (149 B)
Min 87 (87 B)
Max 215 (215 B)
Column Count:
Columns | Count (%) Histogram
5 | 1048576 (100) OO
Percentiles
50th 5
75th 5
95th 5
98th 5
99th 5
Min 5
Max 5
Estimated cardinality: 1029815
EncodingStats minTTL: 0
EncodingStats minLocalDeletionTime: 144288 (09/21/2015 17:00:00)
EncodingStats minTimestamp: 1588980982231688 (05/08/2020 16:36:22)
KeyType: org.apache.cassandra.db.marshal.UUIDType
ClusteringTypes: []
StaticColumns:
RegularColumns: author:org.apache.cassandra.db.marshal.UTF8Type,
isbn:org.apache.cassandra.db.marshal.UTF8Type,
publisher:org.apache.cassandra.db.marshal.UTF8Type,
category:org.apache.cassandra.db.marshal.UTF8Type,
product_name:org.apache.cassandra.db.marshal.UTF8Type
Is Transient: false{noformat}
Status: Patch Available (was: Open)
> C* 4.0 is missing a way to identify transient SSTables on disk
> --
>
> Key: CASSANDRA-15806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15806
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: sequoyha pelletier
>Assignee: sequoyha pelletier
>Priority: Normal
> Fix For: 4.0
>
> Attachments: 15806-4.0.txt
>
>
> Currently, there is no way to identify SSTables that were created as
> transient replicated data. Even thought the feature is experimental we should
> open that up for those that want to experiment. This seems to be an
> oversight. I have added the missing line of code to the SStableMetadataViewer
> and will attach a patch shortly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15806) C* 4.0 is missing a way to identify transient/non-transient SSTables on disk
[ https://issues.apache.org/jira/browse/CASSANDRA-15806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sequoyha pelletier updated CASSANDRA-15806: --- Summary: C* 4.0 is missing a way to identify transient/non-transient SSTables on disk (was: C* 4.0 is missing a way to identify transient SSTables on disk) > C* 4.0 is missing a way to identify transient/non-transient SSTables on disk > > > Key: CASSANDRA-15806 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15806 > Project: Cassandra > Issue Type: Bug > Components: Tool/sstable >Reporter: sequoyha pelletier >Assignee: sequoyha pelletier >Priority: Normal > Fix For: 4.0 > > Attachments: 15806-4.0.txt > > > Currently, there is no way to identify SSTables that were created as > transient replicated data. Even thought the feature is experimental we should > open that up for those that want to experiment. This seems to be an > oversight. I have added the missing line of code to the SStableMetadataViewer > and will attach a patch shortly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15806) C* 4.0 is missing a way to identify transient SSTables on disk
[ https://issues.apache.org/jira/browse/CASSANDRA-15806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sequoyha pelletier updated CASSANDRA-15806: --- Bug Category: Parent values: Correctness(12982) Complexity: Low Hanging Fruit Discovered By: User Report Fix Version/s: 4.0 Severity: Normal Status: Open (was: Triage Needed) > C* 4.0 is missing a way to identify transient SSTables on disk > -- > > Key: CASSANDRA-15806 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15806 > Project: Cassandra > Issue Type: Bug > Components: Tool/sstable >Reporter: sequoyha pelletier >Assignee: sequoyha pelletier >Priority: Normal > Fix For: 4.0 > > Attachments: 15806-4.0.txt > > > Currently, there is no way to identify SSTables that were created as > transient replicated data. Even thought the feature is experimental we should > open that up for those that want to experiment. This seems to be an > oversight. I have added the missing line of code to the SStableMetadataViewer > and will attach a patch shortly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15806) C* 4.0 is missing a way to identify transient SSTables on disk
[ https://issues.apache.org/jira/browse/CASSANDRA-15806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sequoyha pelletier updated CASSANDRA-15806: --- Attachment: 15806-4.0.txt > C* 4.0 is missing a way to identify transient SSTables on disk > -- > > Key: CASSANDRA-15806 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15806 > Project: Cassandra > Issue Type: Bug > Components: Tool/sstable >Reporter: sequoyha pelletier >Assignee: sequoyha pelletier >Priority: Normal > Attachments: 15806-4.0.txt > > > Currently, there is no way to identify SSTables that were created as > transient replicated data. Even thought the feature is experimental we should > open that up for those that want to experiment. This seems to be an > oversight. I have added the missing line of code to the SStableMetadataViewer > and will attach a patch shortly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15806) C* 4.0 is missing a way to identify transient SSTables on disk
sequoyha pelletier created CASSANDRA-15806: -- Summary: C* 4.0 is missing a way to identify transient SSTables on disk Key: CASSANDRA-15806 URL: https://issues.apache.org/jira/browse/CASSANDRA-15806 Project: Cassandra Issue Type: Bug Components: Tool/sstable Reporter: sequoyha pelletier Assignee: sequoyha pelletier Currently, there is no way to identify SSTables that were created as transient replicated data. Even thought the feature is experimental we should open that up for those that want to experiment. This seems to be an oversight. I have added the missing line of code to the SStableMetadataViewer and will attach a patch shortly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11152) SOURCE command in CQLSH 3.2 requires that "use keyspace" is in the cql file that you are sourcing
[
https://issues.apache.org/jira/browse/CASSANDRA-11152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
sequoyha pelletier updated CASSANDRA-11152:
---
Labels: (was: patch)
> SOURCE command in CQLSH 3.2 requires that "use keyspace" is in the cql file
> that you are sourcing
> -
>
> Key: CASSANDRA-11152
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11152
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: CQLSH 3.2.1
>Reporter: Francesco Animali
>
> a difference in behaviour between SOURCE command in CQLSH 3.1 and 3.2.
> In CQLSH 3.1 SOURCE will NOT require "use keyspace" in the cql file that you
> execute: the "keyspace" directive in the qlshrc file will work and the cql
> file will be executed.
> In CQLSH 3.2.1, SOURCE command requires that "use keyspace" is in the cql
> file that you are sourcing, otherwise it throws this error:
> "No keyspace has been specified. USE a keyspace, or explicitly specify
> keyspace.tablename".
> The "keyspace" directive in cqlshrc is overridden by source command.
> steps to reproduce:
> create a file called select.cql in your home directory:
> {noformat}
> echo "CONSISTENCY ONE;" > select.cql
> echo "select * from tab;" >> select.cql
> {noformat}
> in cqlsh:
> {noformat}
> create KEYSPACE kspace WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> create TABLE tab ( id int primary key);
> insert into tab (id) VALUES ( 1);
> {noformat}
> Add this to cqlsgrc:
> {noformat}
> [authentication]
> keyspace = kspace
> {noformat}
> Then exit cqlsh and rerun cqlsh using the cqlshrc just modified.
> Note that you are in keyspace "kspace".
> execute:
> {noformat}
> source 'select.cql'
> {noformat}
> this will have different behaviour in CQLSH 3.2 and 3.1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11152) SOURCE command in CQLSH 3.2 requires that "use keyspace" is in the cql file that you are sourcing
[
https://issues.apache.org/jira/browse/CASSANDRA-11152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
sequoyha pelletier updated CASSANDRA-11152:
---
Flags: (was: Patch)
> SOURCE command in CQLSH 3.2 requires that "use keyspace" is in the cql file
> that you are sourcing
> -
>
> Key: CASSANDRA-11152
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11152
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: CQLSH 3.2.1
>Reporter: Francesco Animali
>
> a difference in behaviour between SOURCE command in CQLSH 3.1 and 3.2.
> In CQLSH 3.1 SOURCE will NOT require "use keyspace" in the cql file that you
> execute: the "keyspace" directive in the qlshrc file will work and the cql
> file will be executed.
> In CQLSH 3.2.1, SOURCE command requires that "use keyspace" is in the cql
> file that you are sourcing, otherwise it throws this error:
> "No keyspace has been specified. USE a keyspace, or explicitly specify
> keyspace.tablename".
> The "keyspace" directive in cqlshrc is overridden by source command.
> steps to reproduce:
> create a file called select.cql in your home directory:
> {noformat}
> echo "CONSISTENCY ONE;" > select.cql
> echo "select * from tab;" >> select.cql
> {noformat}
> in cqlsh:
> {noformat}
> create KEYSPACE kspace WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> create TABLE tab ( id int primary key);
> insert into tab (id) VALUES ( 1);
> {noformat}
> Add this to cqlsgrc:
> {noformat}
> [authentication]
> keyspace = kspace
> {noformat}
> Then exit cqlsh and rerun cqlsh using the cqlshrc just modified.
> Note that you are in keyspace "kspace".
> execute:
> {noformat}
> source 'select.cql'
> {noformat}
> this will have different behaviour in CQLSH 3.2 and 3.1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10234) Add nodetool gettraceprobability command
sequoyha pelletier created CASSANDRA-10234: -- Summary: Add nodetool gettraceprobability command Key: CASSANDRA-10234 URL: https://issues.apache.org/jira/browse/CASSANDRA-10234 Project: Cassandra Issue Type: Improvement Components: Core Reporter: sequoyha pelletier Priority: Trivial nodetool has a settraceprobability command but there is no way to get the value from the nodetool command. Attaching patch that adds the gettraceprobability command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10234) Add nodetool gettraceprobability command
[ https://issues.apache.org/jira/browse/CASSANDRA-10234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sequoyha pelletier updated CASSANDRA-10234: --- Attachment: trunk-10234.txt > Add nodetool gettraceprobability command > > > Key: CASSANDRA-10234 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10234 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: sequoyha pelletier >Priority: Trivial > Attachments: trunk-10234.txt > > > nodetool has a settraceprobability command but there is no way to get the > value from the nodetool command. Attaching patch that adds the > gettraceprobability command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10234) Add nodetool gettraceprobability command
[ https://issues.apache.org/jira/browse/CASSANDRA-10234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sequoyha pelletier updated CASSANDRA-10234: --- Fix Version/s: 3.x > Add nodetool gettraceprobability command > > > Key: CASSANDRA-10234 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10234 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: sequoyha pelletier >Priority: Trivial > Labels: newbie, patch > Fix For: 3.x > > Attachments: trunk-10234.txt > > > nodetool has a settraceprobability command but there is no way to get the > value from the nodetool command. Attaching patch that adds the > gettraceprobability command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-10234) Add nodetool gettraceprobability command
[ https://issues.apache.org/jira/browse/CASSANDRA-10234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sequoyha pelletier reassigned CASSANDRA-10234: -- Assignee: sequoyha pelletier > Add nodetool gettraceprobability command > > > Key: CASSANDRA-10234 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10234 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: sequoyha pelletier >Assignee: sequoyha pelletier >Priority: Trivial > Labels: newbie, patch > Fix For: 3.x > > Attachments: trunk-10234.txt > > > nodetool has a settraceprobability command but there is no way to get the > value from the nodetool command. Attaching patch that adds the > gettraceprobability command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-9348) Nodetool move output should be more user friendly if bad token is supplied
sequoyha pelletier created CASSANDRA-9348:
-
Summary: Nodetool move output should be more user friendly if bad
token is supplied
Key: CASSANDRA-9348
URL: https://issues.apache.org/jira/browse/CASSANDRA-9348
Project: Cassandra
Issue Type: Improvement
Reporter: sequoyha pelletier
Priority: Trivial
If you put a token into nodetool move that is out of range for the partitioner
you get the following error:
{noformat}
[architect@md03-gcsarch-lapp33 11:01:06 ]$ nodetool -h 10.11.48.229 -u
cassandra -pw cassandra move \\-9223372036854775809
Exception in thread main java.io.IOException: For input string:
-9223372036854775809
at org.apache.cassandra.service.StorageService.move(StorageService.java:3104)
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:606)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
at
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at
com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:468)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
at
javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1427)
at
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
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:556)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
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:745)
{noformat}
This ticket is just requesting that we catch the exception an output something
along the lines of Token supplied is outside of the acceptable range for
those that are still in the Cassandra learning curve.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9286) Add Keyspace/Table details to CollectionType.java error message
[
https://issues.apache.org/jira/browse/CASSANDRA-9286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
sequoyha pelletier updated CASSANDRA-9286:
--
Description:
The error message for too many element in a collection does not give keyspace
or column family information. This makes it a pain point to try to determine
which table is the offending table.
Example Error message:
{noformat}
ERROR [Native-Transport-Requests:809453] 2015-04-23 22:48:21,189
CollectionType.java (line 116) Detected collection with 136234 elements, more
than the 65535 limit. Only the first 65535 elements will be returned to the
client. Please see http://cassandra.apache.org/doc/cql3/CQL.html#collections
for more details.
{noformat}
Currently, to try to pinpoint the table in question. We need to trace all
requests and then try to match up the timestamps in the CQL tracing session
with the log timestamps to try and match. If prepared statements are used, this
is a dead end due to the logged tracing information missing the query. In which
case, we have to look at other 3rd party methods for capturing the queries to
try and match up. This is extremely tedious when many tables have collections
and a high number of ops against them.
Requesting that the error contain the keyspace.table name in the error message.
was:
The error message for too many element in a collection does not give keyspace
or column family information. This makes it a pain point to try to determine
which table is the offending table.
Example Error message:
{noformat}
ERROR [Native-Transport-Requests:809453] 2015-04-23 22:48:21,189
CollectionType.java (line 116) Detected collection with 136234 elements, more
than the 65535 limit. Only the first 65535 elements will be returned to the
client. Please see http://cassandra.apache.org/doc/cql3/CQL.html#collections
for more details.
{norformat}
Currently, to try to pinpoint the table in question. We need to trace all
requests and then try to match up the timestamps in the CQL tracing session
with the log timestamps to try and match. If prepared statements are used, this
is a dead end due to the logged tracing information missing the query. In which
case, we have to look at other 3rd party methods for capturing the queries to
try and match up. This is extremely tedious when many tables have collections
and a high number of ops against them.
Requesting that the error contain the keyspace.table name in the error message.
Add Keyspace/Table details to CollectionType.java error message
---
Key: CASSANDRA-9286
URL: https://issues.apache.org/jira/browse/CASSANDRA-9286
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: sequoyha pelletier
Priority: Minor
The error message for too many element in a collection does not give keyspace
or column family information. This makes it a pain point to try to determine
which table is the offending table.
Example Error message:
{noformat}
ERROR [Native-Transport-Requests:809453] 2015-04-23 22:48:21,189
CollectionType.java (line 116) Detected collection with 136234 elements, more
than the 65535 limit. Only the first 65535 elements will be returned to the
client. Please see http://cassandra.apache.org/doc/cql3/CQL.html#collections
for more details.
{noformat}
Currently, to try to pinpoint the table in question. We need to trace all
requests and then try to match up the timestamps in the CQL tracing session
with the log timestamps to try and match. If prepared statements are used,
this is a dead end due to the logged tracing information missing the query.
In which case, we have to look at other 3rd party methods for capturing the
queries to try and match up. This is extremely tedious when many tables have
collections and a high number of ops against them.
Requesting that the error contain the keyspace.table name in the error
message.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-9286) Add Keyspace/Table details to CollectionType.java error message
sequoyha pelletier created CASSANDRA-9286:
-
Summary: Add Keyspace/Table details to CollectionType.java error
message
Key: CASSANDRA-9286
URL: https://issues.apache.org/jira/browse/CASSANDRA-9286
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: sequoyha pelletier
Priority: Minor
The error message for too many element in a collection does not give keyspace
or column family information. This makes it a pain point to try to determine
which table is the offending table.
Example Error message:
{noformat}
ERROR [Native-Transport-Requests:809453] 2015-04-23 22:48:21,189
CollectionType.java (line 116) Detected collection with 136234 elements, more
than the 65535 limit. Only the first 65535 elements will be returned to the
client. Please see http://cassandra.apache.org/doc/cql3/CQL.html#collections
for more details.
{norformat}
Currently, to try to pinpoint the table in question. We need to trace all
requests and then try to match up the timestamps in the CQL tracing session
with the log timestamps to try and match. If prepared statements are used, this
is a dead end due to the logged tracing information missing the query. In which
case, we have to look at other 3rd party methods for capturing the queries to
try and match up. This is extremely tedious when many tables have collections
and a high number of ops against them.
Requesting that the error contain the keyspace.table name in the error message.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
