cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-445) commitlog may consider writes flushed, that are not yet
Date Thu, 17 Sep 2009 16:46:58 GMT


Jonathan Ellis commented on CASSANDRA-445:

I think this approach will work, so +1.

Two comments:

            memtable_.put(key, columnFamily);

should change to

            initialMemtable.put(key, columnFamily);

to emphasize that apply always puts it into the memtable that was live at the start of the
call, and the switch is now done by Table.

there seems to be a high degree of overlap between memtableLock_ and flusherLock_ -- both
are serializing access to a flush-related activity (that is, post-CASSANDRA-444).  I think
memtableLock could be removed now with a little work.

> commitlog may consider writes flushed, that are not yet
> -------------------------------------------------------
>                 Key: CASSANDRA-445
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Jun Rao
>            Priority: Critical
>             Fix For: 0.5
>         Attachments: issue445.patchv1
> 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