Почему в смайлике «весна-кролик» смелые удаляют заголовки сообщения?

Question

В instrumentation-spring-rabbit модуле, храбрый извлекает и удаляет заголовки, почему?

Я исследовал другие приборы (spring-web, httpclient, okhttp3, grpc и другие) смелый никогда не удаляет заголовки - которые содержат клавиши трассировки / дополнительные функции - из исходного сообщения.

Удаление заголовков имеет побочный эффект, когда повтор перехватчик - уже добавлен spring-rabbit - пытается во второй раз обработать сообщение, но потому что brave удалил заголовки в первом повторном запуске, поэтому он не найдет его в последующемretrials.

Answer 1

трассировка сообщений отличается от обычной трассировки RPC двумя основными способами.Поскольку это не так, сравнение с RPC не лучший способ определить путь вперед.Здесь я кратко упомяну пару вещей, которые в основном относятся к слайд-колоде , которую я сделал по этой теме.

1. В сообщениях часто не передается контекст потока междупотребитель и обработчик сообщений.Это не похоже на RPC, где обычно происходит передача обслуживания по крайней мере на стороне запроса.
2. Когда у нас есть контекст потока, мы должны использовать его для установления родительской информации (это имеет место при обработке кролика).Однако часто это не так.Таким образом, мы часто повторно сериализуем заголовки сообщения, когда не знаем абстракцию обработки сообщений.

В случае вашего примера вы говорите о spring-rabbit, который во время блока обработкииспользует контекст потока, чтобы установить «текущий диапазон» соответственно.Поскольку мы не хотим путать контекст, основанный на потоках, с тем, что находится в сообщении, мы очищаем заголовки.

Случай "повторных попыток" действительно ставит это под вопрос.Каким должен быть родитель в этом случае, и как это будет известно?Одна из проблем, связанных с рассматриваемым инструментарием, заключается в том, что мы на самом деле не видим код, использовавший сообщение.

Конкретно, инструментария опроса rabbitmq не существует, поэтому мы добавили «поддельный интервал потребителей» задним числомучитывать это.Если сообщение было воспроизведено ... возможно, допустим второй интервал.Честно говоря, мы не учитывали это.

В любом случае, я хочу сказать, что мы не должны слишком сильно фокусироваться на разнице между отслеживанием сообщений и RPC, поскольку там будут некоторые преднамеренные различия.Давайте сосредоточимся на самом разрыве и, вероятно, сделаем это на gitter, что, по-моему, приведет к проблеме github.

В любом случае, я надеюсь, что контекст отвечает на ваш вопрос, даже если он не меняет того факта, что кодв настоящее время делает то, что делает.

Answer 2

@ Andrain Спасибо за ваш ответ и вашу поддержку, это действительно помогло.

В качестве обходного пути нам нужно переместить перехватчик повторения вниз по цепочке.

@Bean
@Order
BeanPostProcessor reorderingSimpleRabbitListenerContainerFactory() {
    return new BeanPostProcessor() {
        @Override
        public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {

            if (SimpleRabbitListenerContainerFactory.class.isAssignableFrom(bean.getClass())) {

                final Class<RetryOperationsInterceptor> retryInterceptor = RetryOperationsInterceptor.class;
                Advice[] adviceChain = ((SimpleRabbitListenerContainerFactory) bean).getAdviceChain();
                Arrays.sort(adviceChain, (o1, o2) -> {
                    if (o1.getClass().isAssignableFrom(retryInterceptor)) {
                        return 1;
                    }
                    if (o2.getClass().isAssignableFrom(retryInterceptor)) {
                        return -1;
                    }
                    return 0; // it is stable sort, so no worry
                });
            }
            return bean;
        }
    };
}