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

Issue #1664 Cancel Scheduled SpeculativeReads #1665

Closed
wants to merge 2 commits into from

Conversation

jvrao
Copy link
Contributor

@jvrao jvrao commented Sep 7, 2018

If configured every read request schedules a Future task
to send speculative reads on speculativeReadTimeout.
When the read is completed successfully, this task must be
canceled otherwise it leads to memory consumption and under
heavy load the tasks get accumulated which forces lengthy
GC cycles. These lengthy GC cycles may cause ZK lease expiry
and all other sorts of problems eventually resulting in application
errors.

This fix makes sure that the scheduled Futures are cancelled
at the end of read task.

Signed-off-by: Venkateswararao Jujjuri (JV) vjujjuri@salesforce.com
(@ref Andrey@)

Descriptions of the changes in this PR:

Motivation

(Explain: why you're making that change, what is the problem you're trying to solve)

Changes

(Describe: what changes you have made)

Master Issue: #


In order to uphold a high standard for quality for code contributions, Apache BookKeeper runs various precommit
checks for pull requests. A pull request can only be merged when it passes precommit checks. However running all
the precommit checks can take a long time, some trivial changes don't need to run all the precommit checks. You
can check following list to skip the tests that don't need to run for your pull request. Leave them unchecked if
you are not sure, committers will help you:

  • [skip bookkeeper-server bookie tests]: skip testing org.apache.bookkeeper.bookie in bookkeeper-server module.
  • [skip bookkeeper-server client tests]: skip testing org.apache.bookkeeper.client in bookkeeper-server module.
  • [skip bookkeeper-server replication tests]: skip testing org.apache.bookkeeper.replication in bookkeeper-server module.
  • [skip bookkeeper-server tls tests]: skip testing org.apache.bookkeeper.tls in bookkeeper-server module.
  • [skip bookkeeper-server remaining tests]: skip testing all other tests in bookkeeper-server module.
  • [skip integration tests]: skip docker based integration tests. if you make java code changes, you shouldn't skip integration tests.
  • [skip build java8]: skip build on java8. ONLY skip this when ONLY changing files under documentation under site.
  • [skip build java9]: skip build on java9. ONLY skip this when ONLY changing files under documentation under site.


Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

If this PR is a BookKeeper Proposal (BP):

  • Make sure the PR title is formatted like:
    <BP-#>: Description of bookkeeper proposal
    e.g. BP-1: 64 bits ledger is support
  • Attach the master issue link in the description of this PR.
  • Attach the google doc link if the BP is written in Google Doc.

Otherwise:

  • Make sure the PR title is formatted like:
    <Issue #>: Description of pull request
    e.g. Issue 123: Description ...
  • Make sure tests pass via mvn clean apache-rat:check install spotbugs:check.
  • Replace <Issue #> in the title with the actual Issue number.

If configured every read request schedules a Future task
to send speculative reads on speculativeReadTimeout.
When the read is completed successfully, this task must be
canceled otherwise it leads to memory consumption and under
heavy load the tasks get accumulated which forces lengthy
GC cycles. These lengthy GC cycles may cause ZK lease expiry
and all other sorts of problems eventually resulting in application
errors.

This fix makes sure that the scheduled Futures are cancelled
at the end of read task.

Signed-off-by: Venkateswararao Jujjuri (JV) <vjujjuri@salesforce.com>
(@ref Andrey@)
@@ -353,7 +373,7 @@ public void testSpeculativeReadScheduling() throws Exception {
}
Thread.sleep(1000);
}
assertTrue("Request should be done", req0.isComplete());
assertTrue("Request should be done", req.isComplete());
Copy link
Contributor

Choose a reason for hiding this comment

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

good catch

Copy link
Contributor

@eolivelli eolivelli left a comment

Choose a reason for hiding this comment

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

+1 lgtm

@eolivelli
Copy link
Contributor

eolivelli commented Sep 7, 2018

@jvrao please fix spotbugs, then I will be happy to merge and cherry pick

2018-09-07T05:12:27.274 [INFO] Starting audit...
[ERROR] /home/jenkins/jenkins-slave/workspace/bookkeeper_precommit_pullrequest_validation@2/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/ReadLastConfirmedAndEntryOp.java:28:8: Unused import: java.util.concurrent.ScheduledExecutorService. [UnusedImports]
Audit done.

Copy link
Contributor

@dlg99 dlg99 left a comment

Choose a reason for hiding this comment

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

LGTM

@jvrao
Copy link
Contributor Author

jvrao commented Sep 10, 2018

Java9 failure is on Twitter stats; Is that flaky or something I should look into? can we merge this? @sijie ?

@eolivelli
Copy link
Contributor

rerun java9 tests

@eolivelli
Copy link
Contributor

retest this please

@sijie sijie added this to the 4.9.0 milestone Sep 10, 2018
@sijie sijie closed this in cdd6594 Sep 10, 2018
sijie pushed a commit that referenced this pull request Sep 10, 2018
Descriptions of the changes in this PR:

If configured every read request schedules a Future task
to send speculative reads on speculativeReadTimeout.
When the read is completed successfully, this task must be
canceled otherwise it leads to memory consumption and under
heavy load the tasks get accumulated which forces lengthy
GC cycles. These lengthy GC cycles may cause ZK lease expiry
and all other sorts of problems eventually resulting in application
errors.

This fix makes sure that the scheduled Futures are cancelled
at the end of read task.

Signed-off-by: Venkateswararao Jujjuri (JV) <vjujjurisalesforce.com>
(ref Andrey)

Author: JV Jujjuri <vjujjuri@salesforce.com>
Author: Sijie Guo <sijie@apache.org>

Reviewers: Andrey Yegorov <None>, Enrico Olivelli <eolivelli@gmail.com>, Sijie Guo <sijie@apache.org>

This closes #1665 from jvrao/ups_speculative_cancel, closes #1664

(cherry picked from commit cdd6594)
Signed-off-by: Sijie Guo <sijie@apache.org>
sijie pushed a commit that referenced this pull request Sep 10, 2018
Descriptions of the changes in this PR:

If configured every read request schedules a Future task
to send speculative reads on speculativeReadTimeout.
When the read is completed successfully, this task must be
canceled otherwise it leads to memory consumption and under
heavy load the tasks get accumulated which forces lengthy
GC cycles. These lengthy GC cycles may cause ZK lease expiry
and all other sorts of problems eventually resulting in application
errors.

This fix makes sure that the scheduled Futures are cancelled
at the end of read task.

Signed-off-by: Venkateswararao Jujjuri (JV) <vjujjurisalesforce.com>
(ref Andrey)

Author: JV Jujjuri <vjujjuri@salesforce.com>
Author: Sijie Guo <sijie@apache.org>

Reviewers: Andrey Yegorov <None>, Enrico Olivelli <eolivelli@gmail.com>, Sijie Guo <sijie@apache.org>

This closes #1665 from jvrao/ups_speculative_cancel, closes #1664

(cherry picked from commit cdd6594)
Signed-off-by: Sijie Guo <sijie@apache.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants