[
https://issues.apache.org/jira/browse/BOOKKEEPER-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15747191#comment-15747191
]
ASF GitHub Bot commented on BOOKKEEPER-874:
-------------------------------------------
Github user jvrao commented on the issue:
https://github.com/apache/bookkeeper/pull/89
I totally agree that we don't need to have two lac.
We have piggyback LAC on the disk. Your change is to keep it in the cache.
The change we are introducing is digested LAC buffer. This is going to be
more up to date.
Here is what I would propose:
- Have piggyback on the disk; just like how we have it now.
- ExplicitLAC on the fileInfo as we have introduced.
- I am guessing we need to make this work with/without explicitLAC enabled.
If so we need a function in bookie to look at these two versions and get
the latest one.
- Let your Listeners/waiters work on the most updated/available LAC on the
bookie.
On Tue, Dec 13, 2016 at 6:46 PM, Sijie Guo <[email protected]> wrote:
> *@sijie* commented on this pull request.
> ------------------------------
>
> In bookkeeper-server/src/main/java/org/apache/bookkeeper/
> bookie/FileInfo.java <https://github.com/apache/bookkeeper/pull/89>:
>
> > @@ -112,6 +114,29 @@ public long getSizeSinceLastwrite() {
> return sizeSinceLastwrite;
> }
>
> + public ByteBuffer getExplicitLac() {
>
> sure we can discuss this in this week's meeting.
>
> I think there should be only one LAC concept in the bookie server side.
> The LAC is indicating the last add confirmed for a ledger, no matter it is
> a piggyback lac or explicit lac. piggyback and explicit are just different
> ways on advancing the LAC. It should be unified. Otherwise, it is not
going
> to scale.
>
> You patch here is about advancing lac while our change is about
> notifications when lac is advanced. they are not conflicted and are
> actually resolving different problems. I would like to see a unified
> solution - e.g have only one lac or lac buffer in the FileInfo. it would
be
> updated each time lac is advanced (no matter it is advanced or
piggybacked)
> and notify any listeners listening on the lac changes.
>
> Also, I don't like the approach that we did for digesting/checksumming the
> add entries, as it already made the server hard to verify
> digestion/checksum before persisting the entries. We should not use this
> approach for explicit lac. Since we are introducing new type of requests,
> we probably should use this chance to make things right.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/apache/bookkeeper/pull/89>, or mute the thread
>
<https://github.com/notifications/unsubscribe-auth/AAChrkkOAi3ofHj-z_X9VuldPFzNXUWqks5rH1iMgaJpZM4LJZMj>
> .
>
--
Jvrao
---
First they ignore you, then they laugh at you, then they fight you, then
you win. - Mahatma Gandhi
> Explict LAC from Writer to Bookies
> ----------------------------------
>
> Key: BOOKKEEPER-874
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-874
> Project: Bookkeeper
> Issue Type: Improvement
> Components: bookkeeper-client, bookkeeper-server
> Reporter: Venkateswararao Jujjuri (JV)
> Assignee: Venkateswararao Jujjuri (JV)
>
> Current client API piggy-backs LAC with a write. This is keeps reader one
> behind the writer. In order to keep reader up to date with writer even when
> there is a pause in write, proposing the following:
> Writer sends explicit LAC on a configured timeout if there is no write within
> that period.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
