Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
3.9.0
-
None
-
-
Unknown
Description
camel-zipkin reports incorrect span timings when using parallelProcessing with recipientList or multicast pattern.
At the core of the problem is the way camel created copies of Exchange object and copies Properties. Although ExchangeCopyHelper will create a new Exchange object which can then be safely shared with multiple processors, but the operation does not takes into account safe copying of Objects set as properties.
In case of camel-zipkin, ZipkinState is set in the Exchange property. When copies of Exchange objects are created the original ZipkinState object ends up being copied and shared by multiple copies of Exchange object which results in a very messed up information within ZipkinState.
Used the following route to reproduce the problem
restConfiguration()
.component("netty-http")
.host("0.0.0.0")
.port(8081)
.bindingMode(RestBindingMode.json);
rest().get("/demo").produces("text/plain")
.route().recipientList().method(CamelRoute.class).parallelProcessing();
from("direct:a")
.delay(100L)
.to("mock:c");
from("direct:b")
.delay(1000L)
.to("mock:d");
which results in a problematic span. The duration in the below span is incorrect
{"traceId":"68ea85894a4f700c","parentId":"68ea85894a4f700c","id":"202973639d6c6b0b","kind":"CLIENT","name":"direct://a","timestamp":1618418759045044,"duration":1011350,"localEndpoint":\{"serviceName":"direct://a","ipv4":"192.168.56.1"},"tags":{"camel.client.endpoint.url":"direct://b","camel.client.exchange.id":"0A818646BEE6871-0000000000000001","camel.client.exchange.pattern":"InOut"}}