cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jun Rao (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-445) commitlog may consider writes flushed, that are not yet
Date Tue, 15 Sep 2009 23:03:58 GMT


Jun Rao commented on CASSANDRA-445:

hbase actually behaves correctly. Here is the logic. Every update first grabs a read lock,
then gets a log sequence num (increasing) and appends to log, and finally updates memtable
and releases the read lock. The flusher first grabs a write lock, then gets the next LSN (used
as the starting position for log reply), starts the flush and releases the write lock. So,
the flusher waits until all outstanding writes to memtable complete and prevents new writes
while initiating a flush. Updates to memtable are not necessarily in LSN order though.

> commitlog may consider writes flushed, that are not yet
> -------------------------------------------------------
>                 Key: CASSANDRA-445
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Jonathan Ellis
>            Priority: Critical
>             Fix For: 0.5
> Jun Rao explains:
> Suppose there are 3 updates u1, u2, and u3. They are written to commit log in that order.
If u1 and u3 are applied to memtable first and at that point, a flush is triggered. After
the flush completes, it will move the commit log restarting position based on the log for
u3. However, u2 hasn't been persisted on disk yet. This means that if the node dies now, the
recovery logic won't replay u2 from the log.

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

View raw message