Skip to content

[BEAM-1347] Remove the usage of a thread local on a potentially hot path#3260

Closed
lukecwik wants to merge 1 commit into
apache:masterfrom
lukecwik:remove_thread_local
Closed

[BEAM-1347] Remove the usage of a thread local on a potentially hot path#3260
lukecwik wants to merge 1 commit into
apache:masterfrom
lukecwik:remove_thread_local

Conversation

@lukecwik
Copy link
Copy Markdown
Member

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

  • Make sure the PR title is formatted like:
    [BEAM-<Jira issue #>] Description of pull request
  • Make sure tests pass via mvn clean verify.
  • Replace <Jira issue #> in the title with the actual Jira issue
    number, if there is one.
  • If this contribution is large, please file an Apache
    Individual Contributor License Agreement.

@lukecwik
Copy link
Copy Markdown
Member Author

R: @bjchambers

Copy link
Copy Markdown
Contributor

@bjchambers bjchambers left a comment

Choose a reason for hiding this comment

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

LGTM

private final Future<?> bufferedLogWriter;
private final ThreadLocal<Consumer<BeamFnApi.LogEntry>> logEntryHandler;
/**
* Safe object publishing is not required since we only care if the thread that set
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Can you elaborate on the logic here? As far as I can tell, the goal is that the log publishing thread (which is responsible for draining the queue) will only ever offer the message, while other threads will attempt to wait. So we don't need a thread local, we just need to know if this is the thread responsible for draining the queue.

Copy link
Copy Markdown
Member Author

@lukecwik lukecwik May 30, 2017

Choose a reason for hiding this comment

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

This is more of a comment about not needing the volatile key word since the thread that sets it is the only thread that cares that it was set. All other threads compute the same result if it is null. Also, I believe it is adequately explained in the comments surrounding usage/setting in the code.

if (Thread.currentThread() != logEntryHandlerThread) {
// Blocks caller till enough space exists to publish this log entry.
try {
bufferedLogEntries.put(builder.build());
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Should this have a time limit and noisily complain if the queue isn't drained in a reasonable amount of time? I'm thinking about cases where the logging thread mysteriously dies, it would be good to say "unable to put log entry after N minutes".

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Noisily complaining should be part of the container health check or logged to the docker container log. When those exist, this is an excellent place to wire logging as being an issue/bottleneck.

@asfbot
Copy link
Copy Markdown

asfbot commented May 30, 2017

--none--

@asfgit asfgit closed this in 49067b1 May 30, 2017
@lukecwik lukecwik deleted the remove_thread_local branch September 26, 2017 22:13
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.

3 participants