You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bookkeeper.apache.org by "Sijie Guo (JIRA)" <ji...@apache.org> on 2017/07/17 21:29:00 UTC

[jira] [Resolved] (BOOKKEEPER-670) Longpoll Read & Piggyback Support

     [ https://issues.apache.org/jira/browse/BOOKKEEPER-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sijie Guo resolved BOOKKEEPER-670.
----------------------------------
    Resolution: Fixed

all the long poll changes are merged.

> 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.5.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.4.14#64029)