[
https://issues.apache.org/jira/browse/BOOKKEEPER-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13994791#comment-13994791
]
Sijie Guo commented on BOOKKEEPER-670:
--------------------------------------
Changed the ticket to contribute the changes we made to improve read:
- piggyback LAC on read response, so we don't need to poll LAC for reads, which
is very useful for high traffic ledger.
- Longpoll support for reading LAC and piggyback entry if necessary, which is
for low traffic ledger.
> Longpoll Read & Piggyback Support
> ---------------------------------
>
> Key: BOOKKEEPER-670
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-670
> Project: Bookkeeper
> Issue Type: New Feature
> Components: bookkeeper-client, bookkeeper-server
> Reporter: Sijie Guo
> Assignee: Sijie Guo
> Fix For: 4.4.0
>
> Attachments: LACNotificationonBookKeeper.pdf
>
>
> LastAddConfirmed (LAC) is a hint entry id carried on each entry written by a
> ledger writer, which indicates that all the entries before LAC have already
> acknowledged by the writer. So the reader is safe to read all the entries
> written before LAC.
> Currently a bookkeeper reader doesn’t sync LAC with the bookkeeper writer. So
> a bookkeeper reader has to read LAC (aka LedgerHandle#readLastConfirmed)
> before getting the latest entries written by the writer.
> Such polling behavior results in poor performance:
> * Delay on reading entries if we are setting a larger polling interval.
> ** ReadLastConfirm needs to wait all the responses from all bookies in last
> ensemble. This constraint is required for Ledger Recovery Procedure, but not
> for the reader just needs to know latest LAC.
> * It might Introduce useless polling loads to bookie servers if we are
> setting a smaller polling interval.
> A notification mechanism is good to reduce round-trips that a reader spent on
> polling LAC.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
