Unclosed Span leads to OOM and breaks references

[ledor473]

Using the OpenTracingChannelInterceptor class may cause the application to go in OOM because the Span gets started but are not always closed. Also, since the Scope remains active, the references (wrong parent).

In the code below, the Span is created and is made active in the ScopeManager.

java-spring-messaging/opentracing-spring-messaging/src/main/java/io/opentracing/contrib/spring/integration/messaging/OpenTracingChannelInterceptor.java

Lines 71 to 72 in 1c5c758

	Scope scope = tracer.activateSpan(span);
	carrier.addHeader(SCOPE_HEADER, scope);

It's supposed to be closed here:

java-spring-messaging/opentracing-spring-messaging/src/main/java/io/opentracing/contrib/spring/integration/messaging/OpenTracingChannelInterceptor.java

Lines 89 to 93 in 1c5c758

	Object scopeValue = message.getHeaders().get(SCOPE_HEADER);
	if (scopeValue instanceof Scope) {
	Span span = tracer.scopeManager().activeSpan();
	closeResources(ex, (Scope) scopeValue, span);
	}

That logic only works if the application is using a DirectChannel but it's unlikely to work with something like the ExecutorChannel.
Furthermore, it appears that Spring Cloud Stream has a DirectChannel implementation that is not actually "direct" and needs to be excluded according to the code in Sleuth.

Our issue was with the DirectWithAttributesChannel specifically, but the fix we are testing is to only activate the Span if it's a DirectChannel, pass both the Span and Scope in the headers and close both of them in the afterSendCompletion.

[pavolloffay]

thanks for reporting @ledor473, would you like to submit a PR to fix it?

[ledor473]

@pavolloffay yes we are still testing the change but I'll send something as soon as it's fixed