MassTransit генерирует _skipped очереди, которые я хочу игнорировать

Может ли кто-нибудь догадаться, в чем может быть проблема, потому что я не знаю, как ее решить. MassTransit создает очереди _skipped, и я понятия не имею, почему он их создает. Он генерируется при выполнении ответа на запрос публикации.

Клиент запроса создается с использованием следующего метода в 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 отправляется нескольким потребителям, после того, как потребитель отвечает, другой потребитель не знает, куда отвечать, и генерируется мертвое письмо. Но поскольку у нас здесь один потребитель, мы можем исключить эту возможность.

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

Я должен сказать, что в методе Consume в некоторых условиях мы поднимаем RequestTimeoutException и перехватываем его в запрашивающем приложении. Это проверено, и это не создает пропущенных очередей.


person Ozkan    schedule 04.09.2018    source источник
comment
Просто чтобы прояснить для других людей, читающих этот вопрос. RabbitMQ не генерирует очереди с суффиксом _skipped - это должен быть либо Mass Transit, либо код пользователя.   -  person Luke Bakken    schedule 05.09.2018


Ответы (1)


Пропущенная очередь - это очередь недоставленных сообщений. Это означает, что ваша очередь конечных точек привязана к некоторому обмену сообщениями, но для этого сообщения больше нет потребителя. Возможно, вы изменили топологию и переместили потребителя. Вы можете перейти в пользовательский интерфейс управления RMQ и проверить привязки для обмена конечными точками. Если вы посмотрите на сообщения, которые оказались в очереди пропущенных, вы узнаете, какие типы сообщений следует искать.

Биржи названы в честь типов сообщений, поэтому устаревшую привязку будет легко найти.

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

person Alexey Zimarev    schedule 04.09.2018
comment
Я только что проверил привязки, и у каждого типа сообщения, вызывающего пропущенные очереди, есть только одна привязка. что хорошо выглядит ... - person Ozkan; 04.09.2018
comment
Удалось ли определить неправильную привязку? Здесь нет никакого волшебства, если в конечной точке есть потребитель для этого типа сообщения, и сообщения обрабатываются, или сообщения приходят, а у MT нет потребителя для него, и сообщения попадают в очередь недоставленных (пропущенных) сообщений. - person Alexey Zimarev; 04.09.2018
comment
Если вы используете клиент запроса, а на стороне клиента истекло время ожидания (до получения ответа / ошибки от службы), последующий ответ / ошибка на этот запрос окажется в пропущенной очереди. Обязательно установите TTL (срок действия) ответных сообщений, чтобы они не жили дольше, чем таймауты. - person Chris Patterson; 04.09.2018