cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-2823) NPE during range slices with rowrepairs
Date Tue, 28 Jun 2011 08:23:17 GMT

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

Hudson commented on CASSANDRA-2823:
-----------------------------------

Integrated in Cassandra-0.8 #195 (See [https://builds.apache.org/job/Cassandra-0.8/195/])
    Fix potential NPE in range slice read repair
patch by slebresne; reviewed by jbellis for CASSANDRA-2823

slebresne : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1140470
Files : 
* /cassandra/branches/cassandra-0.8/CHANGES.txt
* /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/RowRepairResolver.java
* /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java


> 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
>             Fix For: 0.8.2
>
>         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