cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ariel Weisberg (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9749) CommitLogReplayer continues startup after encountering errors
Date Fri, 14 Aug 2015 17:03:46 GMT


Ariel Weisberg commented on CASSANDRA-9749:

I am struggling here with where to draw the line for testing the code you worked on. I created
CASANDRA-10080 for the missing coverage. I don't think code review and JIRA is the right venue
for deciding whether you should go fill in more test coverage or not.

There are instances of handleReplayError [like this one|]
that throw instead of logging or returning a value. I feel like even when trying to constrain
scope those are things that need to be tested for the change to be done.

So if you are super saturated with 3.0 work that has to be in (no opportunity to constrain
scope) then this is +1. If you could legitimately spend more time on it and make sure the
cases that throw that didn't used to are tested then do that first.

> CommitLogReplayer continues startup after encountering errors
> -------------------------------------------------------------
>                 Key: CASSANDRA-9749
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Blake Eggleston
>            Assignee: Branimir Lambov
>             Fix For: 2.2.x
> There are a few places where the commit log recovery method either skips sections or
just returns when it encounters errors.
> Specifically if it can't read the header here:
> Or if there are compressor problems here:
and here:
> Whether these are user-fixable or not, I think we should require more direct user intervention
(ie: fix what's wrong, or remove the bad file and restart) since we're basically losing data.

This message was sent by Atlassian JIRA

View raw message