[
https://issues.apache.org/jira/browse/BOOKKEEPER-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628777#comment-13628777
]
Ivan Kelly commented on BOOKKEEPER-564:
---------------------------------------
{quote}
1) SyncThread ask ledger storage to persist all the data added before a
mark/checkpoint by calling LedgerStorage#checkpoint
{quote}
If this was how it happened it wouldn't be so bad. But what actually happens is
that LedgerStorage decides it wants a checkpoint, and makes a call that
controls the SyncThread (#startCheckpoint). Eventually this also calls
#checkpointComplete. This is control coupling. It makes LedgerStorage dependent
on the behaviour of SyncThread and makes it impossible to reason about or test
the LedgerStorage in isolation. While this has always been partially the case,
previously SyncThread did control the checkpointing completely, so the flow was
simpler. Now the ledger storage is controlling the checkpointing by means of
the sync thread.
And then, since the journal is controlled by the sync thread in this design, by
inheritance, the journal is controlled by the Ledger storage. I'd actually
prefer a design where the sync thread and the journal were owned by the ledger
storage. At least then the control flow would match the ownership, and the
coupling would be explicit rather than the implicit coupling we have here.
{quote}
the ledger storage does nothing on this above flow, which just tell SyncThread:
"hey, I am dirty enough and it might be the time to do a checkpoint, which
reduces recovery time facing failure".
{quote}
Again, this wouldn't be so bad. But its not the case. What actually happens is
that the ledger storage is saying "hey, checkpoint to this point now!"
> Better checkpoint mechanism
> ---------------------------
>
> Key: BOOKKEEPER-564
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-564
> Project: Bookkeeper
> Issue Type: Improvement
> Components: bookkeeper-server
> Reporter: Sijie Guo
> Assignee: Sijie Guo
> Fix For: 4.3.0
>
> Attachments: 0001-BOOKKEEPER-564-Better-checkpoint-mechanism.patch,
> 0001-BOOKKEEPER-564-Better-checkpoint-mechanism.patch,
> 0002-BOOKKEEPER-564-Better-checkpoint-mechanism.patch, BOOKKEEPER-564.patch,
> BOOKKEEPER-564.patch
>
>
> Currently, SyncThread made a checkpoint too frequently, which affects
> performance. data is writing to entry logger file might be blocked by syncing
> same entry logger file, which affect bookie to achieve higher throughput. We
> could schedule checkpoint only when rotating an entry log file. so new
> incoming entries would be written to newer entry log file and old entry log
> file could be synced.
--
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
