QueueClient.Complete (Guid), похоже, не работает при постановке в очередь другого сообщения в функции, вызванной очередью служебной шины

В Azure WebJobs в классе OnMessageOptions я вызываю метод QueueClient.Complete(Guid), устанавливая для флага AutoComplete значение true, и сообщения, кажется, отлично удаляются из очереди при запуске функции ProcessQueue. Счетчик активных сообщений уменьшается на 1 после успешной обработки каждого сообщения. Однако, когда я хочу повторно поставить сообщение (потому что оно не может быть обработано в настоящее время) обратно в очередь, которая запускает функцию служебной шины, в виде нового сообщения через посредника через минуту, используя BrokeredMessage.ScheduledEnqueueTimeUtc, кажется, что оно не работает. Похоже, что изначально количество запланированных сообщений увеличивается. Я возвращаюсь в очередь через несколько часов и вижу тысячи активных сообщений. Копии одного и того же сообщения. Что происходит? Я ожидал, что сообщение будет удалено из очереди из-за QueueClient.Complete(Guid), и новое запланированное сообщение будет его заменой.

Немного подробностей:

Чтобы отправить сообщение, я делаю следующее:

var queueclient = QueueClient.CreateFromConnectionString(connectionString, queueName);
queueclient.Send(message);
queueclient.close();

Внутри WebJob я создал объект ServiceBusConfiguration, для которого требуется объект onMessageOptions, где я установил AutoComplete=true. Я передаю объект ServiceBusConfiguration методу JobHostConfiguration.UserServiceBus.

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

// если еще не доступно для обработки, подайте заявку повторно ...

var queueclient = QueueClient.CreateFromConnectionString(connectionString, queueName);
    queueclient.Send(message);
    queueclient.close();

Я не делаю следующие / использую обратные вызовы, может быть, поэтому они не работают?

var options = new OnMessageOptions();
options.AutoComplete = false;  // to call complete ourselves

Обратный вызов для обработки полученных сообщений

client.OnMessage(m =>
{

    var clone = m.Clone();
    clone.ScheduledEnqueueTimeUtc = DateTime.UtcNow.AddSeconds(60);
    client.Send(clone);


    m.Complete();

}, options);

person Nothing    schedule 02.04.2019    source источник
comment
Обратите внимание, что вы используете старую библиотеку служебной шины Azure. Хотя это не является причиной вашей проблемы, рассмотрите возможность использования вместо него нового клиента (Microsoft.Azure. ServiceBus).   -  person Sean Feldman    schedule 02.04.2019


Ответы (1)


когда я хочу повторно поставить сообщение (потому что оно не может быть обработано в настоящее время) обратно в очередь, которая запускает функцию служебной шины, как новое сообщение через брокер через минуту, используя BrokeredMessage.ScheduledEnqueueTimeUtc, кажется, что оно не работает

Если вам не удалось обработать сообщение, не ставьте его повторно в очередь. Вместо этого откажитесь (по причине) и его снова заберут.

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

Примечание: когда вы видите поведение, которое, как вы подозреваете, неправильное, очень полезно будет поделиться простой репликой.

person Sean Feldman    schedule 02.04.2019
comment
Хорошо, но я не хочу, чтобы это было мертвой буквой. Я хочу, чтобы его забирали на неопределенный срок, пока он не будет обработан. Нет возможности это сделать? - person Nothing; 02.04.2019
comment
Вы можете отказаться. Он будет получен и повторно обработан снова. - person Sean Feldman; 03.04.2019
comment
.Abandon не мертвая буква это. docs.microsoft. com / en-us / dotnet / api / docs.microsoft.com/en-us/dotnet/api/ - person granadaCoder; 28.05.2019