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 #850: Added request context across client and bookies. #1672

Merged
merged 2 commits into from
Sep 17, 2018

Conversation

dlg99
Copy link
Contributor

@dlg99 dlg99 commented Sep 11, 2018

Descriptions of the changes in this PR:

  • MDC context is passed to runnables, callables etc.
  • protocol extended, context is sent to bookie servers, restored there and back on client with the response.
    Hopefully did not miss some nuance on the server side, largely rely on changes in ordered executors to do all the magic.
  • did microbenchmarking of the protocol changes (strings added to protobuf, MDC context preserved/restored). Looks ok.
  • added unit tests.

(@bug W-5291641@)
(@bug W-5291648@)

Motivation

Troubleshooting of request-level failures/errors can be simplified if request id was passed through all the stages of the request, from threadpools on the client to bookies to the response back on the client.
Log4j/Slf4j allows logging of MDC data so it makes sense to use this functionality for logging.

Changes

  • MDC context is passed to runnables, callables etc.
  • protocol extended, context is sent to bookie servers, restored there and back on client with the response.
    Hopefully did not miss some nuance on the server side, largely rely on changes in ordered executors to do all the magic.
  • did microbenchmarking of the protocol changes (strings added to protobuf, MDC context preserved/restored). Looks ok.
  • added unit tests.

Master Issue: #850


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.

…nt and bookies.

 - MDC context is passed to runnables, callables etc.
 - protocol extended, context is sent to bookie servers, restored theer and back on client with the response.
   Hopefully did not miss some nuance on the server side, largely rely on changes in ordered executors to do all the magic.
 - did microbenchmarking of the protocol changes (strings added to protobuf, MDC context preserved/restored). Looks ok.
 - added unit tests.
@dlg99 dlg99 requested review from sijie and jvrao September 11, 2018 05:46
Copy link
Member

@sijie sijie left a comment

Choose a reason for hiding this comment

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

overall looks great to me. this is a great addon!

Copy link
Member

@jiazhai jiazhai left a comment

Choose a reason for hiding this comment

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

+1, a useful feature.

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.

Awesome !

+1


/**
* Flag describing executor's expectation in regards of MDC.
* All tasks submittedt through executor's submit/execute methods will automatically respect this.
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: s/submittedt/submitted

@@ -412,6 +415,7 @@ private OrderedExecutor createExecutor(
.numThreads(numThreads)
.name(nameFormat)
.traceTaskExecution(serverCfg.getEnableTaskExecutionStats())
.preserveMdcForTaskExecution(serverCfg.getPreserveMdcForTaskExecution())
Copy link
Contributor

Choose a reason for hiding this comment

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

use local cached value instead of getting from conf again?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll leave this the way it is.
createExecutor() is called in the constructor so changing it to the local value creates expectations for the order of the value initialization.
Performance-wise it is a noop since it is only used in the constructor.

break;
}
} finally {
MDC.clear();
Copy link
Contributor

Choose a reason for hiding this comment

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

call it conditionally? Only if the conf is enabled.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought about it, but MDC is not set otherwise so clear (that checks if underlying map is not empty) vs checking for that flag are the same at the end.

Copy link
Contributor

@jvrao jvrao left a comment

Choose a reason for hiding this comment

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

With minor comments; LGTM

@sijie sijie added this to the 4.9.0 milestone Sep 17, 2018
@sijie sijie merged commit c9dc301 into apache:master Sep 17, 2018
reddycharan pushed a commit to reddycharan/bookkeeper that referenced this pull request Oct 17, 2018
…pache#169)

Descriptions of the changes in this PR:

 - MDC context is passed to runnables, callables etc.
 - protocol extended, context is sent to bookie servers, restored there and back on client with the response.
   Hopefully did not miss some nuance on the server side, largely rely on changes in ordered executors to do all the magic.
 - did microbenchmarking of the protocol changes (strings added to protobuf, MDC context preserved/restored). Looks ok.
 - added unit tests.

(bug W-5291641)
(bug W-5291648)

Troubleshooting of request-level failures/errors can be simplified if request id was passed through all the stages of the request, from threadpools on the client to bookies to the response back on the client.
Log4j/Slf4j allows logging of MDC data so it makes sense to use this functionality for logging.

 - MDC context is passed to runnables, callables etc.
 - protocol extended, context is sent to bookie servers, restored there and back on client with the response.
   Hopefully did not miss some nuance on the server side, largely rely on changes in ordered executors to do all the magic.
 - did microbenchmarking of the protocol changes (strings added to protobuf, MDC context preserved/restored). Looks ok.
 - added unit tests.

Master Issue: apache#850

Author: Andrey Yegorov <ayegorov@salesforce.com>

Reviewers: Enrico Olivelli <eolivelli@gmail.com>, Jia Zhai <None>, Venkateswararao Jujjuri (JV) <None>, Sijie Guo <sijie@apache.org>

This closes apache#1672 from dlg99/feature/correlation_id, closes apache#850

@Rev vjujjuri@
@Rev cguttapalem@
@dlg99 dlg99 deleted the feature/correlation_id branch October 14, 2021 23:37
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.

None yet

5 participants