Skip to content
This repository was archived by the owner on Sep 26, 2023. It is now read-only.

Conversation

@igorbernstein2
Copy link
Contributor

@igorbernstein2 igorbernstein2 commented Jan 8, 2019

No description provided.

@igorbernstein2 igorbernstein2 added the do not merge Indicates a pull request not ready for merge, due to either quality or timing. label Jan 8, 2019
@googlebot googlebot added the cla: yes This human has signed the Contributor License Agreement. label Jan 8, 2019
@igorbernstein2 igorbernstein2 changed the title WIP: implement ApiTracer using opencensus api Implement ApiTracer using opencensus api Jan 9, 2019
@codecov
Copy link

codecov bot commented Jan 9, 2019

Codecov Report

Merging #641 into master will increase coverage by 0.23%.
The diff coverage is 82.4%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master     #641      +/-   ##
============================================
+ Coverage     75.22%   75.45%   +0.23%     
- Complexity      971     1000      +29     
============================================
  Files           183      185       +2     
  Lines          4197     4322     +125     
  Branches        335      343       +8     
============================================
+ Hits           3157     3261     +104     
- Misses          887      906      +19     
- Partials        153      155       +2
Impacted Files Coverage Δ Complexity Δ
...main/java/com/google/api/gax/tracing/SpanName.java 80% <100%> (+30%) 4 <1> (+2) ⬆️
...oogle/api/gax/tracing/OpencensusTracerFactory.java 42.85% <42.85%> (ø) 3 <3> (?)
...a/com/google/api/gax/tracing/OpencensusTracer.java 90.29% <90.29%> (ø) 24 <24> (?)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6c8cd40...f96e981. Read the comment docs.

@igorbernstein2 igorbernstein2 removed the do not merge Indicates a pull request not ready for merge, due to either quality or timing. label Jan 9, 2019
@igorbernstein2 igorbernstein2 changed the title Implement ApiTracer using opencensus api WIP: Implement ApiTracer using opencensus api Jan 10, 2019
@igorbernstein2 igorbernstein2 added the do not merge Indicates a pull request not ready for merge, due to either quality or timing. label Jan 10, 2019
@igorbernstein2 igorbernstein2 changed the title WIP: Implement ApiTracer using opencensus api WIP: Opencensus Tracing: Implement ApiTracer using opencensus api Jan 11, 2019
@igorbernstein2 igorbernstein2 removed the do not merge Indicates a pull request not ready for merge, due to either quality or timing. label Jan 11, 2019
@igorbernstein2 igorbernstein2 changed the title WIP: Opencensus Tracing: Implement ApiTracer using opencensus api Opencensus Tracing: Implement ApiTracer using opencensus api Jan 11, 2019
Copy link
Contributor

@vam-google vam-google left a comment

Choose a reason for hiding this comment

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

(Lots of comments, but most of them are minor)

authCredentials: "com.google.auth:google-auth-library-credentials:${authVersion}",
commonProtos: "com.google.api.grpc:proto-google-common-protos:${commonProtosVersion}",
apiCommon: "com.google.api:api-common:1.7.0",
opencensusApi: "io.opencensus:opencensus-api:${opencensusVersion}",

This comment was marked as spam.

This comment was marked as spam.

/** Adds an annotation that the attempt succeeded. */
void attemptSucceeded();

/** Add an annotation that the attempt was cancelled by the user. */

This comment was marked as spam.

This comment was marked as spam.

* Adds an annotation that the attempt failed and that no further attempts will be made because
* retry limits have been reached.
*
* @param error

This comment was marked as spam.

This comment was marked as spam.

* <pre>
* ClientName.ServerStreamingMethod
* - attributes:
* - {@code attempt count}: number of attempts sent before the logical operation completed

This comment was marked as spam.

This comment was marked as spam.

* <p>This implementation wraps an OpenCensus {@link Span} for every tracer and annotates that
* {@link Span} with various events throughout the lifecycle of the logical operation.
*
* <pre>

This comment was marked as spam.

This comment was marked as spam.


attributes.put("attempt count", AttributeValue.longAttributeValue(currentAttemptId + 1));

if (totalAttemptRequests > 0) {

This comment was marked as spam.

This comment was marked as spam.

* <p>This class wraps the {@link Tracer} provided by Opencensus in {@code Tracing.getTracer()}. It
* will be used to create new spans and wrap them in {@link OpencensusTracer} defined in gax.
*/
@InternalApi("For google-cloud-java client use only")

This comment was marked as spam.

This comment was marked as spam.

@InternalApi("Visible for testing")
OpencensusTracerFactory(Tracer internalTracer, @Nullable String clientNameOverride) {
this.internalTracer =
Preconditions.checkNotNull(internalTracer, "internalTracer can't be null");

This comment was marked as spam.

This comment was marked as spam.

* <p>This class wraps the {@link Tracer} provided by Opencensus in {@code Tracing.getTracer()}. It
* will be used to create new spans and wrap them in {@link OpencensusTracer} defined in gax.
*/
@InternalApi("For google-cloud-java client use only")

This comment was marked as spam.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@@ -0,0 +1,355 @@
/*
* Copyright 2018 Google LLC

This comment was marked as spam.

@igorbernstein2
Copy link
Contributor Author

Will address the rest of the feedback shortly. Thanks for reviewing!

@igorbernstein2
Copy link
Contributor Author

All feedback has been addressed. PTAL

Copy link
Contributor

@vam-google vam-google left a comment

Choose a reason for hiding this comment

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

LGTM, but please at least make the OpencensusTracer's fields volatile (it won't harm, performance effect is neglectable, please read the comment for details).

}

private Map<String, AttributeValue> baseOperationAttributes() {
HashMap<String, AttributeValue> attributes = Maps.newHashMap();
Copy link
Contributor

Choose a reason for hiding this comment

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

In any case Maps.newHashMap() should not be used for java 7+ (I think the only reason why it exists is to imitate "diamond" generics in java 6, since they were added in java 7 we can use normal new HashMap<>() (this is what the documentation for Maps.newHashMap() suggests)).

/** {@inheritDoc} */
@Override
public void requestSent() {
attemptSentMessages++;
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure what you mean by adding noise with synchronization here. It is really unnerving to keep a class which will be initizlized/modified/consumed by various threads unsynchronzied (I did read the IBM's article about thread safety categories).

Well, we always can add some "thread friendliness" by doing something like the following:

  1. Make fields (like attemptSentMessages) at at least volatile (to ensure thread visibility).
  2. Or Make them Atomic* (visibility + atomic increments of each field)
  3. Or Synchronize the whole class (could be done in an old-fashioned way of adding synchronize keyword to each method signature, which can greatly reduce amount of boilerplate code, if that is what you meant by noise) (to ensure atomicity of the whole thing).

In any case, this is a reporting class, which does not affect decision-making process and even if updates to it stay non-atomic and/or are not properly syncronized by the outer code the worst thing which can happen is slightly wrong report numbers. Taking that into account can you at least make the non-final fields of method at least volatile (better Anomic) to make me sleep better?

As for performance effect, we already do locking, so it won't change anything drastically. According to Jeff Dean's numbers Mutex lock/unlock is about 25ns (and those are quite old, the google's internal version of the table says around 17ns now). In any case it is quite cheap, especially taking into account how much an actual network call takes.

Copy link
Contributor Author

@igorbernstein2 igorbernstein2 Jan 28, 2019

Choose a reason for hiding this comment

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

In this scenario, there are only 2 threads that are relevant: the caller thread & the grpc thread. The grpc thread is responsible for closing spans and generating annotations.

So the counters that are only modified by the grpc thread dont need any special handling. The other counters (for sending msgs & tracking the attempt number) due need some consideration. I marked them as volatile. I made them atomic. Thanks for catching that.

private final Span span;

private long currentAttemptId;
private long attemptSentMessages = 0;
Copy link
Contributor

Choose a reason for hiding this comment

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

So it is very minor but I'm still curious why these are explicitly set to 0? Especially taking into account that the above one (currentAttemptId) is not.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

currentAttemptId gets stamped, while the others get incremented.

@igorbernstein2 igorbernstein2 merged commit b8923fa into googleapis:master Jan 28, 2019
@igorbernstein2 igorbernstein2 deleted the oc-tracer-impl branch January 28, 2019 22:46
This was referenced Jan 31, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

cla: yes This human has signed the Contributor License Agreement.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants