-
Hello ! Application fetches messages from SQS (in batches), every message is then processed one by one asynchronously. As every message in SQS contains AwsTraceHeader attribute, I tried to use it to create new context :
In that setup created context must be marked as current, and then closed somewhere. Next steps are executed using CompletableFuture/Executors framework, which makes it a bit more complicated. Given very simple example of :
Should I pass the context around manually as an instance and call makeCurrent()/close() in places where it is needed like :
Is this the right (but not very convenient) way to do it? Will this approach create a proper spans ? (I've tried to use this one, looking at the logs - it looks quite right - all the logs have proper trace_id in MDC, but this 'custom' trace is missing in service map in xray (weirdly though, the only missing part is the one from application that was creating the custom span, all the calls to external apps made from that app are in place, with proper 'custom' trace propagated ) Is there a better/more convenient way to achieve this ? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Activating the scope the way you are doing it is definitely the most reliable way. Java agent also has automatic propagation for completable futures where callbacks like try (final Scope ignore = context.makeCurrent()) {
CompletableFuture.supplyAsync(() -> {
//do something with the msg
return processMessage(message);
}, executor)
.thenAccept(msg -> {
ack(msg);
})
.whenComplete((msg, exc) -> {
if (exc != null) {
LOG.info("Processing failed.");
} else {
LOG.info("Processing succeeded.");
}
});
} and see whether it works for you. |
Beta Was this translation helpful? Give feedback.
Activating the scope the way you are doing it is definitely the most reliable way. Java agent also has automatic propagation for completable futures where callbacks like
thenAccept
are called with the context where the future was completed. Note that ifthenAccept
is called on an already completed future thenthenAccept
will be called with the current context. So the alternative you could try is