cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Updated: (CASSANDRA-204) Replayed log data is not flushed before logs are wiped
Date Thu, 28 May 2009 19:47:45 GMT


Jonathan Ellis updated CASSANDRA-204:

    Attachment: 204.patch

Sorry, cleanup got mixed in with the bugfix here.

The fix is, call MT.put instead of putOnRecover.  pOR() didn't set dirty, so it was basically
a broken put().  Removed it.  (Client code goes through apply(), which schedules put() on
the executor.  So recover calling put directly is exactly what we want.)

The rest is removing comments that weren't actually accurate, and making startup messages
more signal than noise (which is what made the problem clear).

> Replayed log data is not flushed before logs are wiped
> ------------------------------------------------------
>                 Key: CASSANDRA-204
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>            Priority: Critical
>         Attachments: 204.patch
> The memtable created by replaying commit logs on startup is supposed to be flushed as
a SSTable before the commitlog is removed, but this is not happening.  So you can lose data
by doing the following:
> 1. insert data
> 2. restart cassandra (using kill, to force replay)
> 3. restart cassandra again

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message