cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-2823) NPE during range slices with rowrepairs
Date Mon, 27 Jun 2011 15:11:47 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13055596#comment-13055596
] 

Sylvain Lebresne commented on CASSANDRA-2823:
---------------------------------------------

Yeah, I didn't do that mostly because there is still a few lines of code (besides maybe scheduling
repair) that we need to do even if resolved is null (debugging message in RowRepairResolver
and more importantly, the clear of versions and versionSources in RangeSliceResolver). 

> NPE during range slices with rowrepairs
> ---------------------------------------
>
>                 Key: CASSANDRA-2823
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2823
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: 0.8.2
>         Environment: This is a trunk build with 2521 and 2433
> I somewhat doubt that is related however.
>            Reporter: Terje Marthinussen
>            Assignee: Sylvain Lebresne
>         Attachments: 2823.patch
>
>
> Doing some heavy testing of relatively fast feeding (5000+ mutations/sec) + repair on
all node + range slices.
> Then occasionally killing a node here and there and restarting it.
> Triggers the following NPE
>  ERROR [pool-2-thread-3] 2011-06-24 20:56:27,289 Cassandra.java (line 3210) Internal
error processing get_range_slices
> java.lang.NullPointerException
> 	at org.apache.cassandra.service.RowRepairResolver.maybeScheduleRepairs(RowRepairResolver.java:109)
> 	at org.apache.cassandra.service.RangeSliceResponseResolver$2.getReduced(RangeSliceResponseResolver.java:112)
> 	at org.apache.cassandra.service.RangeSliceResponseResolver$2.getReduced(RangeSliceResponseResolver.java:83)
> 	at org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:161)
> 	at org.apache.cassandra.utils.MergeIterator.computeNext(MergeIterator.java:88)
> 	at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
> 	at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
> 	at org.apache.cassandra.service.RangeSliceResponseResolver.resolve(RangeSliceResponseResolver.java:120)
> 	at org.apache.cassandra.service.RangeSliceResponseResolver.resolve(RangeSliceResponseResolver.java:43)
> Looking at the code in getReduced:
> {noformat}
>                 ColumnFamily resolved = versions.size() > 1
>                                       ? RowRepairResolver.resolveSuperset(versions)
>                                       : versions.get(0);
> {noformat}
> seems like resolved becomes null when this happens and versions.size is larger than 1.
> RowRepairResolver.resolveSuperset() does actually return null if it cannot resolve anything,
so there is definately a case here which can occur and is not handled.
> It may also be an interesting question if it is guaranteed that                
> versions.add(current.left.cf);
> can never return null?
> Jonathan suggested on IRC that maybe 
> {noformat}
>                 ColumnFamily resolved = versions.size() > 1
>                                       ? RowRepairResolver.resolveSuperset(versions)
>                                       : versions.get(0);
>                 if (resolved == null)
>                       return new Row(key, resolved);
> {noformat}
> could be a fix.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message