cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3303) Short reads protection results in returning more columns than asked for
Date Thu, 20 Oct 2011 14:38:10 GMT

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

Sylvain Lebresne commented on CASSANDRA-3303:
---------------------------------------------

This doesn't always work, because we cannot be sure that on the retry phase, we will have
a digest mismatch again (some read repair could have kicked in). I.e, we should also trim
also in the initial for loop, not only in the 'deal with repair response' one.

Also (and I'm nitpicking a bit) it would be nice to push the trim code into RetriedSliceFromReadCommand
(and to make it handle reversed queries). For instance we could add a filter(ColumFamily)
method or something like that. Same thing for the original count, rather than using instanceof,
I'd rather add a originalCount() method to SliceFromReadCommand (that would return count)
that the Retried variant would override.
                
> Short reads protection results in returning more columns than asked for
> -----------------------------------------------------------------------
>
>                 Key: CASSANDRA-3303
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3303
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.0
>            Reporter: Sylvain Lebresne
>            Assignee: Byron Clark
>            Priority: Minor
>             Fix For: 1.0.1
>
>         Attachments: cassandra-3303-1.patch, cassandra-3303-2.patch, long_read.sh
>
>
> When we detect a short read (in SP.fetchRows), we retry a new command created by:
> {noformat}
> logger.debug("detected short read: expected {} columns, but only resolved {} columns",
sliceCommand.count, liveColumnsInRow);
> int retryCount = sliceCommand.count + sliceCommand.count - liveColumnsInRow;
> SliceFromReadCommand retryCommand = new SliceFromReadCommand(command.table,
>                                                              command.key,
>                                                              command.queryPath,
>                                                              sliceCommand.start,
>                                                              sliceCommand.finish,
>                                                              sliceCommand.reversed,
>                                                              retryCount);
> {noformat}
> That is, in that new command, the count is greater than what asked in the initial command.
But we never cut back the result of that new retried query.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message