From ecf789716b4c0df9e6e7413e6ca2c745487802f0 Mon Sep 17 00:00:00 2001 From: Adrian Cole Date: Mon, 19 Mar 2018 09:41:33 +0800 Subject: [PATCH] Corrects Adrian's rookie move --- .../messaging/TracingChannelInterceptor.java | 28 +++++++++---------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/instrument/messaging/TracingChannelInterceptor.java b/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/instrument/messaging/TracingChannelInterceptor.java index 5cd1c5b52..f44bceddf 100644 --- a/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/instrument/messaging/TracingChannelInterceptor.java +++ b/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/instrument/messaging/TracingChannelInterceptor.java @@ -56,20 +56,20 @@ public final class TracingChannelInterceptor extends ChannelInterceptorAdapter implements ExecutorChannelInterceptor { private static final Log log = LogFactory.getLog(TracingChannelInterceptor.class); - /** - * Using the literal "broker" until we come up with a better solution. - * - *

If the message originated from a binder (consumer binding), there will be different - * headers present (e.g. "KafkaHeaders.RECEIVED_TOPIC" Vs. "AmqpHeaders.CONSUMER_QUEUE" - * (unless the application removes them before sending). These don't represent the broker, - * rather a queue, and in any case the heuristics are not great. At least we might be able - * to tell if this is rabbit or not (ex how spring-rabbit works). We need to think this - * through before making an api, possibly experimenting. - * - *

If the app is outbound only (producer), there's no indication of what type the - * destination broker is. This may hint at a non-manual solution being overwriting the - * remoteServiceName later, similar to how servlet instrumentation lazy set "http.route". - */ + /** + * Using the literal "broker" until we come up with a better solution. + * + *

If the message originated from a binder (consumer binding), there will be different + * headers present (e.g. "KafkaHeaders.RECEIVED_TOPIC" Vs. "AmqpHeaders.CONSUMER_QUEUE" + * (unless the application removes them before sending). These don't represent the broker, + * rather a queue, and in any case the heuristics are not great. At least we might be able + * to tell if this is rabbit or not (ex how spring-rabbit works). We need to think this + * through before making an api, possibly experimenting. + * + *

If the app is outbound only (producer), there's no indication of what type the + * destination broker is. This may hint at a non-manual solution being overwriting the + * remoteServiceName later, similar to how servlet instrumentation lazy set "http.route". + */ private static final String REMOTE_SERVICE_NAME = "broker"; public static TracingChannelInterceptor create(Tracing tracing) {