Spans not being generated for RMI application.

[Samudraneel24]

When using auto-instrumentation with a few RMI applications, spans are not being generated. I went through the tests and I see tests are in place for checking span formation. Am I missing something here?
I’m using java11 and agent version 1.7.2.

Debug logs:
Server.log
Client.log

Application:
JavaCode.zip

[iNikem]

Can you try changing your exporter configuration to -Dotel.traces.exporter=logging for testing? I have a suspicion that your application produces too few spans and exists too quickly and so the common span exporting pipeline has no time to export anything.

[Samudraneel24]

Did not work, the logging exporter isn't exporting the spans.

[Samudraneel24]

I made a small change in the code.
In the UnicastRefInstrumentation.java file, there's this condition check:
if (!Java8BytecodeBridge.spanFromContext(parentContext).getSpanContext().isValid()) { return; }
I commented it out and built the agent locally using ./gradlew assemble. On using this locally built agent, the client side spans are being generated. Although still no server side spans.
My understanding is that this condition check will stop creating a new top level span. But here we want to generate a new client side span.

[laurit]

Currently server spans are only created when you extend UnicastRemoteObject.

[Samudraneel24]

A couple of points:

• You're right about the server side instrumentation. So my suggestion is instead of extendsClass(named("java.rmi.server.RemoteServer")), we can do this: implementsInterface(named("java.rmi.Remote")). The latter condition matches a wider set of possible RMI server implementations. I built it locally, it's working for the app I was using.
• As I wrote in the earlier comment, I think the condition check if (!Java8BytecodeBridge.spanFromContext(parentContext).getSpanContext().isValid()) { return; } shouldn't be there in UnicastRefInstrumentation.java. Thoughts?

[trask]

• As I wrote in the earlier comment, I think the condition check if (!Java8BytecodeBridge.spanFromContext(parentContext).getSpanContext().isValid()) { return; } shouldn't be there in UnicastRefInstrumentation.java. Thoughts?

Some related discussion recently: #4579 (comment)

This condition dates back to the original rmi instrumentation commit DataDog/dd-trace-java#1128, and I could not find any discussion of why it's desirable not to create a rmi client span when there's no parent.

Typically this condition would be used to limit noisy background usage. But without any further info, I would support removing the condition, and if we find that it's too noisy we can revisit and document the decision more clearly.

[Samudraneel24]

Sure, I will raise a PR fixing this.