Samrat Dhillon created CAMEL-16509:
--------------------------------------
Summary: Incorrect span timing information reported by
camel-zipkin when using parallel processing with multicast/recipientList
Key: CAMEL-16509
URL: https://issues.apache.org/jira/browse/CAMEL-16509
Project: Camel
Issue Type: Bug
Components: camel-core, camel-zipkin
Affects Versions: 3.9.0
Environment:
Reporter: Samrat Dhillon
Attachments: zipkin-spans.txt
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"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
