Skip to content

Conversation

AlixBa
Copy link
Contributor

@AlixBa AlixBa commented Jun 8, 2025

First, sorry for the review of 5000 rows, that's not very nice.

This PR aims at instrumenting NATS for both library and java agent, using the messaging conventions.

Few things:

  • I left out JetStreams from the instrumentation for now (as I don't have a particular interest and I have never used)
  • I didn't implement any messaging metrics. I'll take a look after this PR I think.
  • I feel like the java agent advices are very verbose. If there is a better way of doing it, I'll gladly modify what I wrote.

@AlixBa AlixBa requested a review from a team as a code owner June 8, 2025 19:10
@otelbot-java-instrumentation
Copy link
Contributor

🔧 The result from spotlessApply was committed to the PR branch.

@AlixBa
Copy link
Contributor Author

AlixBa commented Jun 9, 2025

@laurit is it you I should ask a review from?

Copy link
Contributor

@laurit laurit left a comment

Choose a reason for hiding this comment

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

Currently there is a build failure, and a test failure.

@AlixBa AlixBa force-pushed the nats-instrumentation branch from fcb32fb to 487dffb Compare June 21, 2025 14:05
@AlixBa AlixBa force-pushed the nats-instrumentation branch from 40e1913 to 7d1b355 Compare June 22, 2025 09:53
@AlixBa AlixBa force-pushed the nats-instrumentation branch from 89cd845 to 360a21f Compare June 22, 2025 10:40
}

/** Returns a {@link Options.Builder} with instrumented {@link DispatcherFactory}. */
public Options.Builder wrap(Options.Builder options) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

not really sure about this, as I have to rely on a build. I think it would be better to let users do options.dispatcherFactory(...) as OpenTelemetryDispatcherFactory is now exposed

@AlixBa
Copy link
Contributor Author

AlixBa commented Jun 22, 2025

hey @laurit

could you have a second look at this one when you have the time?
Took all the comments and followed (I hope) a very close implementation from other messaging instrumentations.

muzzle passes locally and on previous builds, so I guess the error is transient.

@AlixBa
Copy link
Contributor Author

AlixBa commented Jun 27, 2025

might be worth checking if this needs to be applied before merging

@AlixBa AlixBa requested a review from laurit July 1, 2025 11:01
Comment on lines 101 to 109
assertThatNoException()
.isThrownBy(
() -> {
d2.unsubscribe(s1);
d2.unsubscribe(s2);
connection.closeDispatcher(d1);
connection.closeDispatcher(d2);
});
}
Copy link
Contributor

Choose a reason for hiding this comment

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

one way we use for cleanup is


you can call cleanup.deferCleanup(...); immediately after you create whatever needs to be closed/cleaned and it will get executed after the test event when the test fails

Copy link
Contributor Author

@AlixBa AlixBa Sep 12, 2025

Choose a reason for hiding this comment

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

deferCleanup requires AutoCloseable which is not the case for Dispatcher or Subscription.

Also this is to test properly this proxy

  // public void closeDispatcher(Dispatcher dispatcher)
  private Object closeDispatcher(Method method, Object[] args) throws Throwable {
    if (method.getParameterCount() == 1
        && args[0] instanceof Proxy
        && Proxy.getInvocationHandler(args[0]) instanceof OpenTelemetryDispatcher) {
      args[0] = ((OpenTelemetryDispatcher) Proxy.getInvocationHandler(args[0])).getDelegate();
    }

    return invokeMethod(method, delegate, args);
  }

Will the cleanup propagate the error to the test in case this is failing? Because this means that we didn't "unwrap" the otel wrapper, which would fail at runtime

Copy link
Contributor Author

Choose a reason for hiding this comment

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

as per the intended cleanup, it's declared in the abstract parent class

  @AfterAll
  static void afterAll() throws InterruptedException, TimeoutException {
    connection.drain(Duration.ZERO);
    natsContainer.close();
  }

}

@Advice.OnMethodExit(onThrowable = Throwable.class, suppress = Throwable.class)
public static void onExit(@Advice.Enter Message message) {}
Copy link
Contributor

Choose a reason for hiding this comment

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

You should assign message to the message return value otherwise this method will end up returning null which is not what it should be doing. You can verify this by modifying your test to assert on the return value of this method.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

totally forgot to test the return type of the Request methods. Thanks for the reminder!

@laurit laurit added this to the v2.21.0 milestone Sep 17, 2025
@AlixBa
Copy link
Contributor Author

AlixBa commented Sep 17, 2025

@laurit thanks a lot for your time on this

@trask trask merged commit 856f855 into open-telemetry:main Oct 2, 2025
89 checks passed
Copy link
Contributor

otelbot bot commented Oct 2, 2025

Thank you for your contribution @AlixBa! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out this survey.

mznet pushed a commit to mznet/opentelemetry-java-instrumentation that referenced this pull request Oct 3, 2025
Co-authored-by: otelbot <[email protected]>
Co-authored-by: Lauri Tulmin <[email protected]>
Co-authored-by: Jay DeLuca <[email protected]>
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.

4 participants