Обработка времени ожидания сеанса запроса-ответа Azure

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

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

Наша проблема заключается в том, что метод запроса-ответа имеет тайм-аут, который вызывает следующую проблему:

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

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

Спасибо!


azure azureservicebus
person Lucas Kattis    schedule 05.07.2016    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Вы ошиблись, сообщение Time to live of the Azure Service Bus https://msdn.microsoft.com/en-us/library/microsoft.servicebus.messaging.brokeredmessage.timetolive.aspx Это время, в которое сообщение будет находиться в очереди, если он потребляется или нет.

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

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

Это асинхронный процесс, поэтому вы не должны удерживать запросы на его основе, а должны работать с асинхронным характером проблемы.

person Gabriel Monteiro Nepomuceno    schedule 05.07.2016
comment
Спасибо за ваш ответ. Возможно, я недостаточно хорошо объяснил проблему. Я не имею в виду TTL сообщения. Шина Azure поддерживает сеансы, которые используются для сопоставления запроса с ответом. Запрос делается в одной очереди, а ответ предоставляется в другой очереди. Вот пример пример из MSDN. Я имею в виду фактическое свойство timeour, которое необходимо предоставить при создании сеанса. Если этот тайм-аут достигнут и ни один процессор не принял сообщение, то ответ на сообщение никогда не будет получен. - person Lucas Kattis; 06.07.2016
comment
Моя ошибка заключалась в том, что я упомянул очередь недоставленных сообщений, которая, как вы правы, будет использовать TTL очереди. - person Lucas Kattis; 06.07.2016
comment
Вы читали мой комментарий под вашим ответом? Этот вопрос касается организованного процесса, которому необходимо знать, когда все сообщения были обработаны. - person Lucas Kattis; 11.07.2016