[
https://issues.apache.org/jira/browse/BOOKKEEPER-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13623992#comment-13623992
]
Ivan Kelly commented on BOOKKEEPER-564:
---------------------------------------
With BOOKKEEPER-572 the way we checkpoint fundamentally changes though. It's no
longer the case that we can flush/checkpoint the ledger storage and assume that
everything that was in the journal before the flush/checkpoint has now been
persisted. I couldn't see how to fix this in BOOKKEEPER-572, even with the
checkpoint mechanism.
I need to think about this more. I hadn't considered the skiplist case deeply.
Perhaps we need some sort of transaction id. I would like to avoid the storage
making calls to the journal though (even if it is through interfaces).
> 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: 0002-BOOKKEEPER-564-Better-checkpoint-mechanism.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
