Локальная отладка функции Azure - как ограничить ее одним потоком или сообщением?

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

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

{
  "version": "2.0",
  "extensions": {
    "serviceBus": {
      "prefetchCount": 100,
      "messageHandlerOptions": {
        "autoComplete": false,
        "maxConcurrentCalls": 1,
        "maxAutoRenewDuration": "00:55:00"
      }
    }
  }
}

Изменить 1: в настоящее время я запускаю конечную точку администратора функции через HTTP-запрос, который содержит ввод сообщения в теле. Проблема заключается в том, что тело HTTP-запроса должно содержать {"input": "{}"}, и мне приходится тратить время на создание действительного json каждый раз с экранированными двойными кавычками. Было бы намного проще, если бы я мог настроить функцию для одновременного запуска одного сообщения из темы служебной шины.


azureservicebus azure-functions azure-functions-core-tools azure-function-async local
person tubakaya    schedule 22.02.2020    source источник
comment
maxConcurrentCalls делает именно это. Кроме того, вам не нужна предварительная выборка 20. Поскольку это локальная среда, можете ли вы опубликовать одно сообщение и иметь только одно в очереди? Это также будет работать независимо от параллелизма.   -  person Sean Feldman    schedule 22.02.2020
comment
Но этот host.json для меня не имеет никакого значения. Он по-прежнему принимает 16 сообщений. Я не хочу заниматься тем, сколько сообщений отправлено в тему служебной шины. Я ищу способ получать по одному сообщению за раз при отладке.   -  person tubakaya    schedule 22.02.2020
comment
Когда ваша точка останова попадает в первый раз, просто удалите точку останова - вы сможете продолжить для этого конкретного триггера с шагом в / более и т. Д., И вы должны увидеть, что он продолжается для того же триггера даже при переходе в / по вызовам ожидания и так далее.   -  person eli    schedule 23.02.2020
comment
Я не знаю, почему host.json у вас не работает (поднимите вопрос в GitHub). Одно сообщение в очереди должно работать независимо от параллелизма.   -  person Sean Feldman    schedule 23.02.2020
comment
Может быть, вы могли бы попробовать свойство singleton или поделиться своим кодом. И что вы имеете в виду, что запускаете через HTTP-запрос? Вы сказали, что это функция триггера служебной шины.   -  person George Chen    schedule 24.02.2020
comment
Под HTTP-запросом я подразумеваю вызов административного API. На функции, запускаемой служебной шиной, можно по-прежнему запускать через http, сделав запрос к конечной точке функции администратора. Это то, что я имею в виду. Атрибут Singleton тоже не работал, и я также не хочу его использовать, потому что тогда мне нужно будет убедиться, что он не зафиксирован.   -  person tubakaya    schedule 24.02.2020
comment
@SeanFeldman, открою тикет на github. Спасибо за проверку правильности моего понимания параметра maxConcurrentCalls в host.json.   -  person tubakaya    schedule 24.02.2020

Ответы (2)


arrow_upward
0
arrow_downward

Оказалось, что я ошибался в том, как я запускал функцию (мне было стыдно ...). Файл Host.json не был скопирован в папку bin и поэтому не распознан. Конфигурация host.json работает должным образом и ограничивает функцию обработкой одного сообщения за раз.

person tubakaya    schedule 23.02.2021

arrow_upward
-1
arrow_downward

host.json должен быть:

{
  "version": "2.0",
  "extensions": {
    "queues": {
      "batchSize": 1
    }
  }
}
person anacrust    schedule 20.10.2020