You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2016/07/19 13:26:20 UTC
[jira] [Commented] (CASSANDRA-11988) NullPointerExpception when
reading/compacting table
[ https://issues.apache.org/jira/browse/CASSANDRA-11988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15384140#comment-15384140 ]
Sylvain Lebresne commented on CASSANDRA-11988:
----------------------------------------------
I'm a little worried of making the {{filter}} and {{purge}} methods, which depend on {{transformAndFilter}}, behave differently if the row is static or not. The semantic "returns null if everything is filtered" feels easier to remember if you don't add "unless it's a static row, in which case it returns an empty row". And more concretely, I can't swear without concrete inspection that there isn't code that actually expect {{null}} from those method to detect full purge (it's admitedly unlikely in that case though).
Anyway, the issue is that the code expects the {{staticRow()}} method of {{UnfilteredRowIterator}} to never return {{null}} (it's kind of part of its contract even though it's not all that clearly stated right now), and I prefer fixing that by brute-forcing {{BaseRows.staticRow()}} to never return {{null}}.
I'm attaching a patch to do so below. The patch does the same {{AbstractBTreePartition}} to be on the safe side (I believe it's theoretically possible to have the static row null today because {{Row.updateAllTimestamp}} can also theoretically return null, but I'm not sure at all this can be practically triggered).
The patch also adds a few precisions to javadocs regarding those behavior as well as minor cleanups I did while looking at that (apologies on the latter, shouldn't pollute patch like that in general, but figured it's simple enough here and couldn't help myself). I've also added a simple unit test to reproduce the issue for good measure.
Let me know if that work for you.
| [11988-3.0|https://github.com/pcmanus/cassandra/commits/11988-3.0] | [utests|http://cassci.datastax.com/job/pcmanus-11988-3.0-testall] | [dtests|http://cassci.datastax.com/job/pcmanus-11988-3.0-dtest] |
| [11988-3.9|https://github.com/pcmanus/cassandra/commits/11988-3.9] | [utests|http://cassci.datastax.com/job/pcmanus-11988-3.9-testall] | [dtests|http://cassci.datastax.com/job/pcmanus-11988-3.9-dtest] |
> NullPointerExpception when reading/compacting table
> ---------------------------------------------------
>
> Key: CASSANDRA-11988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11988
> Project: Cassandra
> Issue Type: Bug
> Reporter: Nimi Wariboko Jr.
> Assignee: Carl Yeksigian
> Fix For: 3.x
>
>
> I have a table that suddenly refuses to be read or compacted. Issuing a read on the table causes a NPE.
> On compaction, it returns the error
> {code}
> ERROR [CompactionExecutor:6] 2016-06-09 17:10:15,724 CassandraDaemon.java:213 - Exception in thread Thread[CompactionExecutor:6,1,main]
> java.lang.NullPointerException: null
> at org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:38) ~[apache-cassandra-3.6.jar:3.6]
> at org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:64) ~[apache-cassandra-3.6.jar:3.6]
> at org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:24) ~[apache-cassandra-3.6.jar:3.6]
> at org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:76) ~[apache-cassandra-3.6.jar:3.6]
> at org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:226) ~[apache-cassandra-3.6.jar:3.6]
> at org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182) ~[apache-cassandra-3.6.jar:3.6]
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) ~[apache-cassandra-3.6.jar:3.6]
> at org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:82) ~[apache-cassandra-3.6.jar:3.6]
> at org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60) ~[apache-cassandra-3.6.jar:3.6]
> at org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:264) ~[apache-cassandra-3.6.jar:3.6]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_45]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_45]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[na:1.8.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {code}
> Schema:
> {code}
> CREATE TABLE cmpayments.report_payments (
> reportid timeuuid,
> userid timeuuid,
> adjustedearnings decimal,
> deleted set<timeuuid> static,
> earnings map<timeuuid, decimal>,
> gross map<timeuuid, decimal>,
> organizationid text,
> payall timestamp static,
> status text,
> PRIMARY KEY (reportid, userid)
> ) WITH CLUSTERING ORDER BY (userid ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> 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 = '99PERCENTILE';
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)