[
https://issues.redhat.com/browse/WFLY-13866?page=com.atlassian.jira.plugi...
]
Radoslav Husar commented on WFLY-13866:
---------------------------------------
I am not that familiar with opentracing, but if it relies on thread local, that's not
going to work in async case. [~lthon] can shed more light into the matter.
Several traces created in Jaeger for just one method call
---------------------------------------------------------
Key: WFLY-13866
URL:
https://issues.redhat.com/browse/WFLY-13866
Project: WildFly
Issue Type: Bug
Components: MP OpenTracing
Affects Versions: 21.0.0.Beta1
Reporter: Fabio Burzigotti
Assignee: Emmanuel Hugonnet
Priority: Major
Fix For: 21.0.0.Beta1
I am migrating one opentracing/fault-tolerance test from Thorntail TS [1] and I noticed
that Wildfly SNAPSHOT is behaving differently with respect to what in the subject.
The test is pretty simple, deploying a REST app which makes use of injected service which
in turn leverages microprofile opentracing (via API) and fault-tolerance (via
annotations). The test executes the following 2 methods in the given order:
- call {{hello}}, which is synchronous and is throwing an exception, hence failing and
gets called again then ending up with the fallback. This generates 1 trace with 4 spans in
Jaeger and the behavior is consistent between TT and WildFly
- call {{helloAsync}}, which is asynchronous and is throwing an exception, hence failing
and getting called again (asynchronously?) then ending up with the fallback. This
generates the following traces in Jaeger:
TT: 1 trace with 4 spans
WildFly: 4 separate traces , i.e. the one for the REST endpoint GET method, two for the
{{helloAsync}} calls and one for the fallback.
[1]
https://github.com/rhoar-qe/thorntail-test-suite/tree/master/microprofile...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)