[
https://issues.apache.org/jira/browse/BOOKKEEPER-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16044624#comment-16044624
]
ASF GitHub Bot commented on BOOKKEEPER-1093:
--------------------------------------------
Github user sijie commented on the issue:
https://github.com/apache/bookkeeper/pull/180
you still need to call "readLastAddConfirmed". This change is not "long
poll", it is "piggy-back lac". It is an optimization on reducing the times of
calling readLastAddConfirmed. In a tailing case, most of the time you should
call getLastAddConfirmed, you keep reading until your current read entry is
moving beyond the value that #getLastAddConfirmed, which means you caught up
with the writer then you switch to call #readLastAddConfirmed. since lac is
piggy-back, so the value returned by #readLastConfirmed is advancing, hence you
don't need to call #readLastAddConfirmed that often.
> Piggyback LAC on ReadResponse
> -----------------------------
>
> Key: BOOKKEEPER-1093
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-1093
> Project: Bookkeeper
> Issue Type: Sub-task
> Components: bookkeeper-client, bookkeeper-server
> Reporter: Sijie Guo
> Assignee: Sijie Guo
> Fix For: 4.5.0
>
>
> Currently LAC is only updated when the reader explicitly calls
> #readLastAddConfirmed(). In tailing-read use cases, it will not wise to keep
> calling #readLastAddConfirmed, especially when the traffic is huge.
> The idea here is piggy-back LAC along with the read responses. so the client
> will get advanced LAC along with read responses. so it will reduce calling
> #readLastAddConfirmed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
