在儀器化彈簧兔子模塊中，Brave正在提取和刪除標頭，為什么？我探索了其他工具（，，，，，和其他）勇敢地從不從原始消息中刪除標頭 - 這些標頭包含跟蹤鍵/附加內(nèi)容。spring-webhttpclientokhttp3grpc刪除標頭會產(chǎn)生副作用，其中重試偵聽器（已由 spring-rabbit 添加）正在第二次嘗試處理消息，但由于在第一次重審中刪除了標頭，因此在后續(xù)重審中找不到它。brave
2 回答
猛跑小豬
TA貢獻1858條經(jīng)驗 獲得超8個贊
郵件跟蹤在兩個主要方面與典型的 RPC 跟蹤不同。因為它是不同的，所以與RPC相比并不是找出前進道路的最佳方法。我將在這里簡要提及幾件事，這些事情主要在我為該主題制作的幻燈片中。
在消息傳遞中，通常沒有在使用者和消息處理器之間傳遞線程上下文。這與 RPC 不同，RPC 通常至少在請求端有一個切換。
當我們有一個線程上下文時，我們應該使用它來建立父信息（兔子處理就是這種情況）。但是，情況往往并非如此。因此，當我們不知道消息傳遞處理抽象時，我們經(jīng)常重新序列化消息上的標頭。
在你的例子中，你說的是spring-rabbit，它在處理塊期間使用線程上下文來適當?shù)卦O置“當前跨度”。由于我們不想將基于線程的上下文與消息中的內(nèi)容混淆，因此我們清除了標頭。
“重試”案確實對此提出了質(zhì)疑。在這種情況下，父母應該是什么，如何知道？有問題的檢測的一個問題是，我們實際上沒有看到使用消息的代碼。
具體來說，rabbitmq輪詢工具不存在，所以我們放了一個“假的消費者跨度”來追溯性地解釋這一點。如果消息已重新播放。也許第二個消費者跨度是有效的。坦率地說，我們沒有考慮這一點。
無論如何，我的觀點是，我們不應該過分關注消息傳遞跟蹤和RPC之間的差異，因為那里會有一些有意的差異。讓我們專注于差距本身，并可能在gitter上這樣做，我認為這會導致github問題。
無論如何，我希望上下文可以回答您的問題，即使它不會改變代碼當前執(zhí)行其功能的事實。
慕后森
TA貢獻1802條經(jīng)驗 獲得超5個贊
作為一種解決方法，我們需要將重試攔截器沿鏈向下移動。
@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;
}
};
}
添加回答
舉報
0/150
提交
取消