Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BOOKKEEPER-965: Long Polling Part I: Changes in the write path #73

Closed
wants to merge 1 commit into from

Conversation

robindh
Copy link

@robindh robindh commented Nov 8, 2016

This is the first in the series of changes for enabling long polling between bookkeeper client and the bookkeeper server. The changes were originally implemented in the Twitter fork and these pull request combine multiple commits from Twitter's bookkeeper fork as they include not only the changes made initially but also bug fixes added since.

The first change captures the changes on the write path (AddEntry). We track the last add confirmed in the FileInfo so that we can trigger actions when the value is updated

@sijie
Copy link
Member

sijie commented Nov 9, 2016

LGTM +1

@jvrao this is our first change about the long poll read request. I know you guys are also working on the lac related change. Can you also take a look this change to make sure it will be compatible with your change.

@jvrao
Copy link
Contributor

jvrao commented Nov 9, 2016

This directly corresponds to what we have been using and have local changes. You are aware of our change. Is this something you worked on recently? if so, I am wondering why to reinvent the wheel instead of using our patch.

@sijie
Copy link
Member

sijie commented Nov 9, 2016

@jvrao no, this is the old change at Twitter's branch. we are merging these changes back.

@sijie
Copy link
Member

sijie commented Nov 12, 2016

@jvrao @merlimat can any of you take a look? so we can send the subsequent changes out.

Copy link
Contributor

@merlimat merlimat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@@ -80,6 +80,9 @@
private int stateBits;
private boolean needFlushHeader = false;

// lac
private Long lac = null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this used as an optimization to quickly find the highest LAC sent by the writer?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes. it will also be used for the subsequent long poll change. so we can detect the lac changes and satisfy any long poll wait requests.

@sijie
Copy link
Member

sijie commented Nov 14, 2016

@jvrao if there is no objection from you, I'd like to merge this and move on sending the subsequent requests.

@asfgit asfgit closed this in 9359d68 Nov 17, 2016
@jvrao
Copy link
Contributor

jvrao commented Nov 19, 2016

@sijie Sorry responding after it is pulled in. Do you know how-much savings you are getting with this? I have changes in similar lines but to keep explicitLac in FileInfo. Read path may be little more complicated. I will watch out for it. In the mean time I will push my changes too.

@sijie
Copy link
Member

sijie commented Nov 21, 2016

@jvrao what do you mean saving? you mean the long poll change?

@jvrao
Copy link
Contributor

jvrao commented Nov 21, 2016

@sijie Saving = perf benefit.
This whole thing is to cache the LAC in FileInfo rather than reaching out on the disk and read it.
IMO the last entry must be in buffer cache and no need to hit the disk. So I was little surprised to see you went this far to cache the LAC in FileInfo, hence wondering if you have any measurements
on how much perf benefit you got with this change.

@sijie
Copy link
Member

sijie commented Nov 21, 2016

@jvrao gotcha. we didn't measure that in particularly. the most benefit we have with this is we can have long poll requests satisfied when lac is advanced. FileInfo is the best place to us to implement this feature.

kishorekasi pushed a commit to kishorekasi/bookkeeper that referenced this pull request Jul 18, 2017
This is the first in the series of changes for enabling long polling between bookkeeper client and the bookkeeper server. The changes were originally implemented in the Twitter fork and these pull request combine multiple commits from Twitter's bookkeeper fork as they include not only the changes made initially but also bug fixes added since.

The first change captures the changes on the write path (AddEntry). We track the last add confirmed in the FileInfo so that we can trigger actions when the value is updated

Author: Robin Dhamankar <robindh@Robins-MacBook-Air.local>

Reviewers: sijie@apache.org <sijie@apache.org>

Closes apache#73 from robindh/LongPollWritePath
sijie pushed a commit to sijie/bookkeeper that referenced this pull request Jan 26, 2018
Author: xieliang <xieliang007@gmail.com>

Reviewers: Sijie Guo <sijie@apache.org>, Leigh Stewart <lstewart@apache.org>

Closes apache#73 from xieliang/DL-28
kishorekasi pushed a commit to kishorekasi/bookkeeper that referenced this pull request Feb 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants