[
https://issues.apache.org/jira/browse/BOOKKEEPER-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13636209#comment-13636209
]
Ivan Kelly commented on BOOKKEEPER-572:
---------------------------------------
{quote}
since we don't have 'COMMIT' and 'ABORT' part to an modification in journal
side, it is not trivial or even difficult to get rid of buggy record (in db
concept, incomplete txn). for now, it might be OK as you said to detect
exception and use prevalidation. but it is difficult to maintain or extend in
future (for example, if we want to introduce CAS for metadata purpose). so I am
-1 on reversing the order to keep journal have clean and validated
entries.{quote}
I disagree. If a buggy record doesn't crash the bookie when first being
applied, there's no reason it should crash it when being replayed from the
journal. But im not wedded entirely to the reorder as long as we can resolve
the BOOKKEEPER-447 issue cleanly in some other fashion.
{quote}
I don't introduce a separate set or lookaside cache, just when a page is
written back to filesystem, I wrote it in a different place. so I need to keep
a separate index for tracking the index page and its position. This index is in
page-level, so it would not introduce too much memory comparing with the
lookaside cache.
I don't finished this work, since it is just one hack project for me. I spent
less time on it. for now, I just have a prototype on the storage format for new
ledger index:
https://github.com/sijie/bookkeeper/commit/a5b2e79b58765692ac8d5f9f7c62a1ea7110ea68
{quote}
This sounds like a completely different design for the index cache. Is there a
design doc for this? The changelist you posted doesn't show where this fits
into the current design.
> Make the journal a write ahead log
> ----------------------------------
>
> Key: BOOKKEEPER-572
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-572
> Project: Bookkeeper
> Issue Type: Bug
> Reporter: Ivan Kelly
> Assignee: Ivan Kelly
> Fix For: 4.3.0
>
> Attachments:
> 0001-BOOKKEEPER-572-Write-to-the-journal-before-writing-t.patch,
> 0001-BOOKKEEPER-572-Write-to-the-journal-before-writing-t.patch,
> 0001-BOOKKEEPER-572-Write-to-the-journal-before-writing-t.patch,
> 0001-BOOKKEEPER-572-Write-to-the-journal-before-writing-t.patch,
> 0003-BOOKKEEPER-572-Write-to-the-journal-before-writing-t.patch,
> 0003-BOOKKEEPER-572-Write-to-the-journal-before-writing-t.patch,
> BookieServer-2013-02-22.snapshot
>
>
> A bookie adds to the LedgerStorage before writing to the journal. This is the
> fundamental problem behind BOOKKEEPER-447 and blocks a nice solution to
> BOOKKEEPER-530. By writing to the memory state before the journal, we exposed
> ourselves to bugs if the bookie crashed before we wrote to the journal. The
> entry may exist in index, but not in the entrylog, a situation which cannot
> be distinguished from an I/O error. The comments on BOOKKEEPER-447 goes into
> more details.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
