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

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

Код для отправки запланированного BrokeredMessage очень нормальный:

var message = new BrokeredMessage(info);
message.Properties.Add("Action", "Bookmark");
message.ContentType = "Info";
message.ScheduledEnqueueTimeUtc = DateTime.UtcNow.AddMinutes(Int32.Parse(ConfigurationManager.AppSettings["Delay"]));
var serviceBusClient = QueueClient.CreateFromConnectionString(ConfigurationManager.AppSettings["ConnectionString"], ConfigurationManager.AppSettings["ServiceBusQueueName"]);
serviceBusClient.Send(message);

Из 20 000 сообщений, которые я отправил во время тестирования, только 6 сообщений зависали, причем в случайное время.

Ниже приведен снимок экрана в режиме отладки. Снимок экрана с недопустимым ExpiresAtUtc

Примечания: Первоначально я думал, что сообщения застревают из-за неправильного ExpiresAtUtc, но после некоторого чтения обнаружил, что при планировании нового сообщения его ExpiresAtUtc составляет 31.12.9999 11:59:59 PM Также я обнаружил, что когда сообщения планируются путем клонирования сообщения из очереди, то ExpiresAtUtc для запланированного сообщения не будет 12/31/9999 11:59:59 PM, а будет его правильным временем ExpiresAtUtc, даже если оно запланировано очередь


person user844105    schedule 14.09.2017    source источник
comment
Это не проблема. ExpiresAtUtc по умолчанию присвоено 9999 году.   -  person Mikhail Shilkov    schedule 14.09.2017
comment
Во-первых, как сказал Михаил, ExpiresAtUtc запланированного BrokeredMessage по умолчанию присваивается 9999 году. Во-вторых, в в этой статье мы можем найти: Message enquing time does not mean that the message will be sent at the same time.It will get enqueued, but the actual sending time depends on the queue's workload and its state.действуют ли те 6 запланированных сообщений, которые не попали в очередь до сегодняшнего дня?   -  person Fei Han    schedule 14.09.2017
comment
Да, @FredHan, даже сегодня они застряли, если вы видите EnqueuedTimeUtc, его 11 сентября, поэтому он застрял в запланированной очереди на последние 3 дня, и в этой очереди нет рабочей нагрузки   -  person user844105    schedule 14.09.2017
comment
Сообщения обычно не застревают. Либо их отложили, либо что-то не так с очередью. Можете ли вы выбрать эти сообщения и убедиться, что они не отложены?   -  person Sean Feldman    schedule 14.09.2017
comment
Привет, @SeanFeldman, они не являются отложенными сообщениями, как вы видите на скриншоте, состояние запланировано. Из 20000 сообщений, которые я обработал в тот день таким же образом, только 6 сообщений не удалось   -  person user844105    schedule 14.09.2017


Ответы (1)


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

Согласно вашему снимку экрана, эти сообщения не становятся активными (состояние сообщения - «Запланировано»), вы можете попытаться вызвать если сообщение можно отменить.

client.CancelScheduledMessageAsync(sequenceNumber)

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

person Fei Han    schedule 15.09.2017
comment
Привет, @FredHan. Я попробовал в соответствии с вашим предложением и обнаружил, что мы используем более старую версию API 2.1.4, а CancelScheduledMessageAsync не работает в этой версии. Я попытался создать новую очередь и оставил демон продолжать отправлять сообщения, ни одно из них не завершилось неудачно (отправлено почти 1 миллион сообщений. - person user844105; 18.09.2017
comment
Кажется, что с этой конкретной очередью что-то не так, как и я, вы можете создать новую очередь для своей программы. Или вы можете попытаться получить помощь от инженера службы поддержки Azure, создав запрос в службу поддержки. - person Fei Han; 19.09.2017
comment
Конечно, я подниму запрос в службу поддержки. - person user844105; 19.09.2017
comment
Я могу создать новую очередь и продолжить, но для меня очень важно знать, что не так с текущей очередью, потому что, если то же самое произойдет в производственной среде, это огромная потеря. - person user844105; 19.09.2017
comment
if the same happens in production, its a huge loss Я согласен с вами. Вы создаете запрос в службу поддержки? Если инженер службы поддержки Azure поможет вам найти проблему с этой конкретной очередью, вы можете поделиться с нами. - person Fei Han; 20.09.2017
comment
Конечно, @FredHan, я буду - person user844105; 22.09.2017