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

[improvement] Add support for tracing-aware Guava FutureCallbacks. #77

Open
wants to merge 5 commits into
base: develop
Choose a base branch
from

Conversation

dsd987
Copy link
Contributor

@dsd987 dsd987 commented Feb 19, 2019

Before this PR

Functionality defined as part of a Guava FutureCallback may not be correctly traced as the thread it runs on may not be the thread adding the callback.

After this PR

FutureCallbacks can be wrapped such that their traces are parented to the thread adding the callback or wrapped in a new trace if desired.

@dsd987 dsd987 requested a review from a team as a code owner February 19, 2019 19:42
/**
* Like {@link #wrapWithNewTrace(String, Callable)}, but for Guava's FutureCallback.
*/
public static <V> FutureCallback<V> wrapWithNewTrace(String operation, FutureCallback<V> delegate) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think we ever want to create a new trace around just the callback

Copy link
Contributor

@carterkozak carterkozak left a comment

Choose a reason for hiding this comment

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

@ellisjoe is putting some thought into support for tracing asynchronous operations as well.

ListenableFuture<Void> success = listeningExecutorService.submit(() -> null);
ListenableFuture<Void> failure = listeningExecutorService.submit(() -> {
throw new IllegalStateException();
});
Copy link
Contributor

Choose a reason for hiding this comment

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

should use separate test cases for the successful/failed futures. Otherwise when tests fail, it. takes additional debugging to figure out what the problem is.

ListenableFuture<Void> success = listeningExecutorService.submit(() -> null);
ListenableFuture<Void> failure = listeningExecutorService.submit(() -> {
throw new IllegalStateException();
});
Copy link
Contributor

Choose a reason for hiding this comment

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

Should use separate test cases for these

@@ -104,6 +106,11 @@ public static Runnable wrap(Runnable delegate) {
return new TracingAwareRunnable(delegate);
}

/** Like {@link #wrap(Callable)}, but for Guava's FutureCallback. */
public static <V> FutureCallback<V> wrap(FutureCallback<V> delegate) {
return new TracingAwareFutureCallback<>(delegate);
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this take an operation name? Once #71 merges DeferredTracer can take an operation name. I'd prefer we we required an operation name for new methods, and did not provide a method using a default.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure. Can wait until #71 merges and then rebase to use the DeferredTracer with the operation name.

Tracer.startSpan("before-construction");
FutureCallback<Void> successCallback = Tracers.wrap(futureCallback);
Tracer.startSpan("after-construction");
Futures.addCallback(success, successCallback, MoreExecutors.directExecutor());
Copy link
Contributor

Choose a reason for hiding this comment

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

We should have a test that runs on an executor using a different thread, since tracing-java heavily uses thread state. The direct executor just invokes run() on the current thread.

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.

2 participants