cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Branimir Lambov (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9749) CommitLogReplayer continues startup after encountering errors
Date Wed, 12 Aug 2015 15:32:47 GMT


Branimir Lambov commented on CASSANDRA-9749:

[Branch|] updated.

bq. Boolean.getBoolean() can check the system property


bq. What is the motivation for changing this to warn? Is it going to cause operators concern
that is unwarranted?

The patch includes a general heightening of the message severity for replay problems (what
was warnings before are now errors, even when they are ignored). Let me know if you prefer
to keep it as info.

bq. Do you have to make all those object arrays for handleReplayError? varargs won't handle
it correctly?

Apparently eclipse does this when you ask it to inline a method with varargs. Fixed, apologies
for not noticing it myself.

bq. Some of the error conditions that now are supposed to throw don't have unit test coverage.
They weren't tested before either, but this an opportunity to make sure the errors work.

Fixed the existing tests which were only hitting the invalid descriptor path and added tests
for the newer log formats that include a descriptor.

> 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