-
-
Notifications
You must be signed in to change notification settings - Fork 407
Conversation
@@ -101,7 +101,7 @@ Our `pom.xml` already imports Jaeger: | |||
<dependency> | |||
<groupId>com.uber.jaeger</groupId> | |||
<artifactId>jaeger-core</artifactId> | |||
<version>0.26.0</version> | |||
<version>0.27.0</version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should change it to io.jaegertracing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, ok. I didn't know this package has been moved to io.jaegertracing:jaeger-core. The java package names have changed, so imports and fully qualified class references would have to be updated too. I can update this pull request with these changes as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
I think you have noticed as well, but we are on 0.310. already, so, a version bump to that one would be good.
Tracer tracer = Tracing.init("hello-world"); | ||
new Hello(tracer).sayHello(helloTo); | ||
tracer.close(); | ||
try (Tracer tracer = Tracing.init("hello-world")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the tracer closable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tracer is com.uber.jaeger.Tracer in this class, which implements the Closeable interface. io.opentracing.Tracer, however, does not extend the Closeable interface.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[off-topic] Would be a good improvement for OpenTracing :)
SamplerConfiguration samplerConfig = new SamplerConfiguration("const", 1); | ||
ReporterConfiguration reporterConfig = new ReporterConfiguration(true, null, null, null, null); | ||
Configuration config = new Configuration(service, samplerConfig, reporterConfig); | ||
SamplerConfiguration samplerConfig = new SamplerConfiguration().withType("const").withParam(1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about we use a simple Configuration.fromEnv(serviceName).getTracer()
here in the code and export the relevant env vars?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jpkrohling, I just started learning OpenTracing, so I'm not familiar with "export the relevant env vars", yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough. This is particular to Jaeger (not generic OpenTracing), and it might indeed confuse users. For reference, I'm talking about JAEGER_REPORTER_LOG_SPANS
, JAEGER_SAMPLER_TYPE
and JAEGER_SAMPLER_PARAM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you change this to use fromEnv()
, like what we are doing in the Katacoda scenario? We override some env vars there, so, fromEnv()
is required there (even though it's not required here).
Hi @yurishkuro and @jpkrohling, I pushed a commit that upgrades to io.jaegertracing:jaeger-core:0.31.0. |
Tracer tracer = Tracing.init("hello-world"); | ||
new Hello(tracer).sayHello(helloTo); | ||
tracer.close(); | ||
try (JaegerTracer tracer = Tracing.init("hello-world")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, the tutorial should be using OT's Tracer instead of JaegerTracer as much as possible. The side effect is that, at least for now, we'd need to close the tracer manually (see jaegertracing/jaeger-client-java#544).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That said, we could change the tutorial later, once we fix the mentioned issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I absolutely agree! I have changed the code and lesson01/README.md to reflect this.
Hi @yurishkuro and @jpkrohling, I caught a mistake in the work I had done to upgrade Jaeger to 0.31.0. The mistake was that the lessons stopped communicating with Jaeger that's running in Docker. The reason for this is due to the fact that in 0.31.0, it seems that the service provider for SenderFactory does not live in jaeger-core any more. It took a bit of digging, but I found ThriftSenderFactory in jaeger-thrift. This was elusive, because there were no compile-time or runtime errors to help me realize something was wrong. The reason I realized something was wrong is by noticing the "No suitable sender found. Using NoopSender, meaning that data will not be sent anywhere!" WARN message in the log. I have updated pom.xml and the README.md. |
@SevaSafris use |
if you're removing the calls to tracer.close(), you will not get clean traces, unless we implement JVM shutdown hook in Jaeger. |
@yurishkuro, regarding tracer.close(): The close method is defined in io.jaegertracing.internal.JaegerTracer, but it is not defined in io.opentracing.Tracer. If we keep the tracer.close() method call, then the Hello class becomes implementation specific to Jaeger as the OT vendor. Perhaps the close() method should be added to io.opentracing.Tracer? |
@yurishkuro said:
I submitted a PR last week to add this. It should be available in the next version of the client. @SevaSafris said:
I believe so too, but this should probably be discussed/suggested as an issue opened against https://github.com/opentracing/opentracing-java . Would you be interested in starting a discussion there about this? |
@yurishkuro, I submitted a new issue for discussion here. |
What's the status of this? I'd like to run through the Katacoda scenarios and see if anything is broken, as it uses this code here. |
@@ -45,6 +45,5 @@ public static void main(String[] args) { | |||
String helloTo = args[0]; | |||
Tracer tracer = Tracing.init("hello-world"); | |||
new HelloActive(tracer).sayHello(helloTo); | |||
tracer.close(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'll still need this until we release 0.31.1, which includes the JVM shutdown hook.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have been waiting for opentracing/opentracing-java#250 and opentracing/specification#128 to move forward with the Closeable spec, but it seems this will take a while. I've updated this pull request to upcast to JaegerTracer in a try-resource block.
This LGTM, but please let's not get it merged until at least Tuesday, as @yurishkuro is presenting on Monday and will use this repo. As the Katacoda scenarios use the same code base, this has potential to break the scenarios. I'll try to get the scenarios up to date next week, in line with this PR, unless @SevaSafris wants to give it a shot as well. The repository is this: https://github.com/katacoda-scenarios/opentracing-scenarios |
@jpkrohling, apologies for the delayed response -- I'm just getting over a cold. Regarding the scenarios: I have my full focus on the java-agent right now, and won't be able to get around to the scenarios until next week perhaps. |
Don't worry! I'm starting to check the Katacoda scenarios based on this branch and will send a PR with the required fixes to that repo. |
SamplerConfiguration samplerConfig = new SamplerConfiguration("const", 1); | ||
ReporterConfiguration reporterConfig = new ReporterConfiguration(true, null, null, null, null); | ||
Configuration config = new Configuration(service, samplerConfig, reporterConfig); | ||
SamplerConfiguration samplerConfig = new SamplerConfiguration().withType("const").withParam(1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you change this to use fromEnv()
, like what we are doing in the Katacoda scenario? We override some env vars there, so, fromEnv()
is required there (even though it's not required here).
<version>0.26.0</version> | ||
<groupId>io.jaegertracing</groupId> | ||
<artifactId>jaeger-client</artifactId> | ||
<version>0.31.0</version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0.32.0, otherwise, you'll need to add the #close()
calls. The 0.32.0 implements the "close on JVM shutdown" feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pavolloffay, is 0.32.0 available on maven central already?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it should be, if it's not I don't want to redo the release 😢
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's there, just confirmed :)
<version>0.31.0</version> | |
<version>0.32.0</version> |
Could we aim to get this merged by tomorrow, preferably today? I'm OK with the changes here, even though I'd prefer to have 0.32.0 instead of 0.31.0 and omit the Once this here is merged, I'll ask @BenHall to merge katacoda-scenarios/opentracing-scenarios#3 |
@jpkrohling you have merge writes here |
That's true :-) Merging! |
Hi @yurishkuro, I went through the lessons in this repository yesterday. The changes in this pull request identify the changes to the OpenTracing APIs since the lessons were written. I also updated run.sh to allow the lessons to run on jdk9+.