[
https://issues.apache.org/jira/browse/CASSANDRA-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15234152#comment-15234152
]
Robert Stupp commented on CASSANDRA-8720:
-----------------------------------------
I like the patch, but it has two issues:
# the size of the last partition is sometimes negative. Example from
compaction_history
{code}
95a04430-fef1-11e5-b65b-6b58859e2c86 442
ea30b2c0-fef9-11e5-b65b-6b58859e2c86 -68
{code}
# it somehow collides with reference counting in 2.2 (but works fine in 2.1):
{code}
Exception in thread "main" java.lang.NullPointerException
at
org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier.setup(SSTableReader.java:2043)
at
org.apache.cassandra.io.sstable.format.SSTableReader.setup(SSTableReader.java:1986)
at
org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:461)
at
org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:363)
at
org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:358)
at
org.apache.cassandra.tools.SSTableExport.enumeratekeys(SSTableExport.java:240)
at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:461)
ERROR 15:16:40 Error when closing class
org.apache.cassandra.io.sstable.format.SSTableReader$DescriptorTypeTidy@1234160209:/Users/snazy/devel/cassandra/2.2/data/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/snapshots/1460131305667/la-10-big
java.lang.NullPointerException: null
at
org.apache.cassandra.io.sstable.format.SSTableReader$DescriptorTypeTidy.tidy(SSTableReader.java:2148)
~[main/:na]
at
org.apache.cassandra.utils.concurrent.Ref$GlobalState.release(Ref.java:283)
~[main/:na]
at
org.apache.cassandra.utils.concurrent.Ref$State.release(Ref.java:183)
~[main/:na]
at org.apache.cassandra.utils.concurrent.Ref.release(Ref.java:77)
[main/:na]
at
org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier$1.run(SSTableReader.java:2086)
[main/:na]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[na:1.8.0_77]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[na:1.8.0_77]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[na:1.8.0_77]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[na:1.8.0_77]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_77]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_77]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_77]
{code}
> Provide tools for finding wide row/partition keys
> -------------------------------------------------
>
> Key: CASSANDRA-8720
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8720
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: J.B. Langston
> Fix For: 2.1.x, 2.2.x
>
> Attachments: 8720.txt
>
>
> Multiple users have requested some sort of tool to help identify wide row
> keys. They get into a situation where they know a wide row/partition has been
> inserted and it's causing problems for them but they have no idea what the
> row key is in order to remove it.
> Maintaining the widest row key currently encountered and displaying it in
> cfstats would be one possible approach.
> Another would be an offline tool (possibly an enhancement to sstablekeys) to
> show the number of columns/bytes per key in each sstable. If a tool to
> aggregate the information at a CF-level could be provided that would be a
> bonus, but it shouldn't be too hard to write a script wrapper to aggregate
> them if not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
