MassTransit生成我想忽略的_skipped队列 [英] MassTransit generates _skipped queues which I want to ignore

查看:79
本文介绍了MassTransit生成我想忽略的_skipped队列的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

任何人都可以猜出问题出在哪里,因为我对如何解决这个问题一无所知.MassTransit生成 _skipped 队列,但我不知道为什么生成这些队列.它是在执行发布请求响应时生成的.

Can anyone guess what the problem can be because I'm clueless on how to solve this. MassTransit generates _skipped queues and I don't have a clue why it is generating those. It is being generated when doing a publish request response.

Request Client是使用MassTransit.RequestClientExtensions

Request Client is created using following method in MassTransit.RequestClientExtensions

public static IRequestClient<TRequest, TResponse> CreatePublishRequestClient<TRequest, TResponse>(this IBus bus, TimeSpan timeout, TimeSpan? ttl = null, Action<SendContext<TRequest>> callback = null) where TRequest : class where TResponse : class
{
  return (IRequestClient<TRequest, TResponse>) new PublishRequestClient<TRequest, TResponse>(bus, timeout, ttl, callback);
}

请求如下:

TResponse response = TaskUtil.Await(() => requestClient.Request(request));

如您所见,这是请求响应"场景,其中请求已发送给所有使用者.但是因为目前我们只有一个消费者,所以只将其发送给该消费者.如果对多个使用者进行了publishrequest-response,则死信很容易出现,一旦一个使用者响应,另一个使用者就不知道在哪里响应,并且产生了死信.但是因为这里只有一个消费者,所以我们可以消除这种可能性.

As you can see this is Request Response scenario where Request is being sent to all consumers. But because at the moment we have only one consumer it only is being sent to that consumer. deadletters appear easily if a publishrequestresponse is done to multiple consumers, once a consumer responds, the other consumer doesn't know where to respond and a deadletter is generated. But because we have one consumer here, we can eliminate this possibility.

那么这些跳过的队列还有其他原因吗?非常感谢您提供有关如何解决此问题的帮助...

So what could be other reasons for these skipped queues? Huge thanks for any help on how I can troubleshoot this...

我不得不说,在Consume方法中,在某种情况下,我们引发一个 RequestTimeoutException 并将其捕获到请求的应用程序中.经过测试,不会产生跳过的队列.

I have to say, in the Consume method, in some condition, we raise a RequestTimeoutException and catch it in the requesting application. This is tested and this doesn't generate skipped queues.

推荐答案

跳过的队列是一个死信队列.这意味着您的终结点队列具有对某些消息交换的绑定,但是不再有该消息的使用者.也许您更改拓扑并移动了使用者.您可以转到RMQ管理UI并检查绑定以进行端点交换.如果您查看最终跳过的队列中的邮件,则会发现要查找的邮件类型.

Skipped queue is a dead letter queue. It means that your endpoint queue has a binding to some message exchange but there is no consumer for that message any longer. Maybe you change the topology and moved the consumer. You can go to the RMQ management UI and check the bindings for your endpoint exchange. If you look at messages that ended up in the skipped queue, you will find out what message types to look for.

交易所是根据消息类型命名的,因此很容易找到过时的绑定.

Exchanges are named after message types so it will be easy to find the obsolete binding.

然后,在管理UI中,您可以手动删除已过时的绑定,并且不再有消息进入跳过的队列.

Then, in the management UI, you can manually remove the binding that is obsolete and there will be no more messages coming to the skipped queue.

这篇关于MassTransit生成我想忽略的_skipped队列的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆