Skip to content
This repository has been archived by the owner on Jul 1, 2022. It is now read-only.

Upgrade to OpenTracing java 0.30.0 with in-process propagation support #188

Merged
merged 6 commits into from
Jun 9, 2017

Conversation

objectiser
Copy link
Contributor

@objectiser objectiser commented May 22, 2017

Resolves #179

Changed all calls to SpanBuilder.start() method to startManual() to avoid deprecation warnings.

@codecov-io
Copy link

codecov-io commented May 23, 2017

Codecov Report

Merging #188 into master will increase coverage by 0.5%.
The diff coverage is 94.44%.

Impacted file tree graph

@@             Coverage Diff             @@
##             master     #188     +/-   ##
===========================================
+ Coverage     80.98%   81.48%   +0.5%     
- Complexity      462      463      +1     
===========================================
  Files            77       77             
  Lines          1793     1804     +11     
  Branches        210      211      +1     
===========================================
+ Hits           1452     1470     +18     
+ Misses          251      244      -7     
  Partials         90       90
Impacted Files Coverage Δ Complexity Δ
...aeger-core/src/main/java/com/uber/jaeger/Span.java 81.44% <ø> (+1.64%) 36 <0> (ø) ⬇️
...a/com/uber/jaeger/filters/jaxrs2/ServerFilter.java 95% <100%> (ø) 7 <0> (ø) ⬇️
...r/jaeger/httpclient/TracingRequestInterceptor.java 84.61% <100%> (ø) 5 <0> (ø) ⬇️
...a/com/uber/jaeger/filters/jaxrs2/ClientFilter.java 82.14% <100%> (ø) 5 <0> (ø) ⬇️
...ger-core/src/main/java/com/uber/jaeger/Tracer.java 87.78% <93.33%> (+0.28%) 17 <3> (+1) ⬆️
...java/com/uber/jaeger/reporters/RemoteReporter.java 90% <0%> (+2.85%) 9% <0%> (ø) ⬇️
...jaeger/reporters/protocols/ThriftUdpTransport.java 81.35% <0%> (+3.38%) 14% <0%> (ø) ⬇️
...c/main/java/com/uber/jaeger/senders/UdpSender.java 74.54% <0%> (+3.63%) 11% <0%> (ø) ⬇️

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 700f744...7d9ce5c. Read the comment docs.

@@ -188,7 +208,7 @@ public void close() {
}

@Override
public io.opentracing.Tracer.SpanBuilder asChildOf(io.opentracing.Span parent) {
public io.opentracing.Tracer.SpanBuilder asChildOf(BaseSpan<?> parent) {
Copy link
Member

Choose a reason for hiding this comment

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

not io.opentracing.BaseSpan?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is io.opentracing.BaseSpan.

Copy link
Member

@yurishkuro yurishkuro left a comment

Choose a reason for hiding this comment

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

given my comments about the build, it seems we're missing unit tests for various scenarios involving the active span


// Check if active span should be established as CHILD_OF relationship
if (!ignoreActiveSpan && null != activeSpanSource.activeSpan()) {
asChildOf(activeSpanSource.activeSpan());
Copy link
Member

Choose a reason for hiding this comment

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

this seems too late, since the new context was already created above.

Copy link
Member

Choose a reason for hiding this comment

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

maybe move it into createNewContext(), to cover the case below

// Check if active span should be established as CHILD_OF relationship
if (!ignoreActiveSpan && null != activeSpanSource.activeSpan()) {
asChildOf(activeSpanSource.activeSpan());
}
} else if (debugId != null) {
context = createNewContext(debugId);
Copy link
Member

Choose a reason for hiding this comment

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

technically this also qualifies for active-spanness

@objectiser
Copy link
Contributor Author

Ok thanks @yurishkuro I will sort it out when back next week.

@pavolloffay
Copy link
Member

We should start deprecating instrumentations and context propagation. It can be done in a separate PR.

@objectiser
Copy link
Contributor Author

@yurishkuro Moved the code into the createNewContext method. What additional unit tests were you thinking about - the PropagationTest has various tests for dealing with the active span?

Copy link
Member

@yurishkuro yurishkuro left a comment

Choose a reason for hiding this comment

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

Sorry for slow response, this week has been very busy.

@@ -169,7 +169,6 @@ private void finishWithDuration(long durationMicros) {
}
}

@Override
public void close() {
Copy link
Member

Choose a reason for hiding this comment

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

should we even have this method? IIRC the OT Span is no longer closable

if (!ignoreActiveSpan && null != activeSpanSource.activeSpan()) {
asChildOf(activeSpanSource.activeSpan());
}

return new SpanContext(id, id, 0, flags);
Copy link
Member

Choose a reason for hiding this comment

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

parentID == 0 and traceID == random() are incorrect if we have a parent span

tracer.buildSpan("child").startActive().deactivate();
}
assertEquals(2, reporter.getSpans().size());
assertEquals("child", reporter.getSpans().get(0).getOperationName());
Copy link
Member

Choose a reason for hiding this comment

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

nit: extract to vars to make the code easier to read

Span childSpan = reporter.getSpans().get(0);
Span parentSpan = reporter.getSpans().get(1);

assertTrue(reporter.getSpans().get(1).getReferences().isEmpty());
assertEquals(References.CHILD_OF, reporter.getSpans().get(0).getReferences().get(0).getType());
assertEquals(reporter.getSpans().get(1).context(),
reporter.getSpans().get(0).getReferences().get(0).getSpanContext());
Copy link
Member

Choose a reason for hiding this comment

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

missing checks:

  • parentSpan.traceID == childSpan.traceID
  • parentSpan.spanID == childSpan.parentID

}
assertEquals(2, reporter.getSpans().size());
assertTrue(reporter.getSpans().get(0).getReferences().isEmpty());
assertTrue(reporter.getSpans().get(1).getReferences().isEmpty());
Copy link
Member

Choose a reason for hiding this comment

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

missing:

  • outerSpan.traceID != inner.traceID
  • innerSpan.parentID == 0

parentId = parentContext.getSpanId();
}

return new SpanContext(traceId, id, parentId, flags);
Copy link
Member

Choose a reason for hiding this comment

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

I think there's another issue - span ID can be unique or inherited from parent depending on zipkinSharedRpcSpan flag. Looking at this with a fresh eye, perhaps this child logic does not belong to createNewContext. Instead, of we move it to the beginning of startManual would the rest just work automatically?

    public io.opentracing.Span startManual() {
        // move here
        if (!ignoreActiveSpan && null != activeSpanSource.activeSpan()) {
               asChildOf((SpanContext) activeSpanSource.activeSpan().context());
        }

      SpanContext context;

      String debugId = debugId();
      if (references.isEmpty()) {
        context = createNewContext(null);
      } else if (debugId != null) {
        context = createNewContext(debugId);
      } else {
        context = createChildContext();
      }

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@yurishkuro Update applied - although not sure it is right, as the conditions for adding the childOf for the active span is that no other explicit references have been added? Possibly it just needs an extract condition - e.g. references.isEmpty() && !ignoreActiveSpan && ... ?

// Check if active span should be established as CHILD_OF relationship
if (!ignoreActiveSpan && null != activeSpanSource.activeSpan()) {
asChildOf(activeSpanSource.activeSpan());
}
Copy link
Member

Choose a reason for hiding this comment

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

lgtm. Just one more thing - reading the API docs, the active span should only be used as a parent if there are no other references added explicitly. So need to add && references. isEmpty

Copy link
Member

Choose a reason for hiding this comment

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

And probably a respective unit test is missing for this scenario.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agree

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will add test soon - have to sign off for a while.

@yurishkuro yurishkuro merged commit e97081c into jaegertracing:master Jun 9, 2017
@yurishkuro
Copy link
Member

Thanks @objectiser !

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants