[
https://issues.apache.org/jira/browse/BOOKKEEPER-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13734657#comment-13734657
]
Flavio Junqueira commented on BOOKKEEPER-670:
---------------------------------------------
Thanks for the proposal, Sijie, here are some thoughts. In general, pushing
notifications is more efficient than polling when changes are infrequent. If
the rate of changes is high, then polling will generate fewer messages, but an
additional one way latency to fetch the LAC. I actually think that's the key
reason for you to propose two modes: EVERY and PERIODICAL. I don't fully
understand the semantics of PERIODICAL, though. Does it periodically notify the
client independent of changes? Or does it send a notification after the end of
the period only in the case that there has been a change?
When you say that polling leads to poor performance, I'm not sure what you're
referring to. If the source of low performance is the delay between polling
requests, then the observation holds only for low rates of changes. Otherwise,
the reader will always have a lot to read between two requests. Actually, if we
use EVERY to learn fast about new values of the LAC when the rate of changes is
high, then we end up with a lot of notification messages, which might not be a
good idea.
> LAC(LastAddConfirmed) Notification Mechanism
> --------------------------------------------
>
> 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
> 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 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
