Сообщения не перенаправляются между модулями Edge

Обновить

Обновление моего вопроса для ясности.

Репозиторий: https://github.com/aaronprince05/IoTEdgeMessaging

У меня есть 2 модуля: MessageGeneratorModule, MessageReceiverModule.

MessageGeneratorModule отправляет:
1000 сообщений в пакете, а затем ждет 4 минуты
1 сообщение в минуту в течение 2 минут
Затем 1 сообщение в секунду в течение 1 минуты
Затем 20 сообщений в секунду в течение 1 минуты

MessageReceiverModule — это стандартный шаблонный код модуля IoT Edge, который просто получает сообщения и регистрирует их. Я удалил код, который отправляет сообщения вверх по течению.

У меня есть конфигурация маршрута в IoT Edge как

{
    "routes": {
        "myRoute": "FROM /messages/modules/messageGenerator/outputs/output INTO BrokeredEndpoint(\"/modules/messageReceiver/inputs/input1\")"
    }
}

Я испытываю здесь некоторый тип дросселирования, когда сообщения не сразу доставляются получателю. Вместо этого доставляется около 10-20 сообщений от общего числа. Следующий набор из 10 сообщений можно принудительно отправить, отправив другое сообщение, чтобы вызвать приемник. (Обратите внимание на временные метки ниже)

Added Cert: /mnt/edgemodule/edge-device-ca.cert.pem
Connection String <my connection string>
IoT Hub module client initialized.
[12/19/2017 18:27:08] Received message: 1, Body: [1]
[12/19/2017 18:27:08] Received message: 2, Body: [2]
[12/19/2017 18:27:08] Received message: 3, Body: [3]
[12/19/2017 18:27:08] Received message: 4, Body: [4]
[12/19/2017 18:27:08] Received message: 5, Body: [5]
[12/19/2017 18:27:08] Received message: 6, Body: [6]
[12/19/2017 18:27:08] Received message: 7, Body: [7]
[12/19/2017 18:27:08] Received message: 8, Body: [8]
[12/19/2017 18:27:08] Received message: 9, Body: [9]
[12/19/2017 18:27:08] Received message: 10, Body: [10]
[12/19/2017 18:27:08] Received message: 11, Body: [11]
[12/19/2017 18:27:08] Received message: 12, Body: [12]
[12/19/2017 18:27:08] Received message: 13, Body: [13]
[12/19/2017 18:27:08] Received message: 14, Body: [14]
[12/19/2017 18:27:08] Received message: 15, Body: [15]
[12/19/2017 18:27:08] Received message: 16, Body: [16]
[12/19/2017 18:27:08] Received message: 17, Body: [17]
[12/19/2017 18:27:08] Received message: 18, Body: [18]
[12/19/2017 18:27:08] Received message: 19, Body: [19]
[12/19/2017 18:27:08] Received message: 20, Body: [20]
[12/19/2017 18:27:08] Received message: 21, Body: [21]
[12/19/2017 18:30:59] Received message: 22, Body: [22]
[12/19/2017 18:30:59] Received message: 23, Body: [23]
[12/19/2017 18:30:59] Received message: 24, Body: [24]
[12/19/2017 18:30:59] Received message: 25, Body: [25]
[12/19/2017 18:30:59] Received message: 26, Body: [26]
[12/19/2017 18:30:59] Received message: 27, Body: [27]
[12/19/2017 18:30:59] Received message: 28, Body: [28]
[12/19/2017 18:30:59] Received message: 29, Body: [29]
[12/19/2017 18:30:59] Received message: 30, Body: [30]
[12/19/2017 18:30:59] Received message: 31, Body: [31]
[12/19/2017 18:31:59] Received message: 32, Body: [32]
[12/19/2017 18:31:59] Received message: 33, Body: [33]
[12/19/2017 18:31:59] Received message: 34, Body: [34]

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


person Aaron Prince    schedule 18.12.2017    source источник


Ответы (2)


Большое спасибо за сообщение об этом. Код, который вы разместили, очень помог в исследовании проблемы. И вы правы, это баг. Итак, я открыл эту проблему здесь, на GitHub, чтобы вы знали, когда она будет исправлена: https://github.com/Azure/iot-edge/issues/455

В основном существует проблема с Edge Hub, когда он получает большие пакеты сообщений за один раз. Итак, в качестве обходного пути, если вы хотите отправить 1000 сообщений, вместо отправки одной партии из 1000 отправляйте несколько пакетов по 10.

Это временно, пока мы не заполним этот вопрос.

[Обновление] Элемент исправлен в выпуске 1.0.0-preview019.

person Angelo Ribeiro    schedule 03.01.2018

Я не уверен, откуда берется _module? Мой модуль, полученный из официального примера, использует DeviceClient следующим образом — в методе MessageHandler:

DeviceClient deviceClient = (DeviceClient)userContext;
// Build your message
//...
await deviceClient.SendEventAsync("output1", identifiedMessage);

Это работает для вас?

person silent    schedule 18.12.2017
comment
_module исходит из класса, который я создал, чтобы абстрагироваться от соединений DeviceClient. Этот класс имеет DeviceClient.CreateFromConnectionString(_connectionString, settings); В любом случае код никогда не достигает await _module.SendMessageAsync(identifiedMessage); для передачи полученного сообщения дальше. Первое, что должен сделать обработчик, это записать Message! к консоли. - person Aaron Prince; 18.12.2017
comment
Ваш код основан на клиентском SDK IoT? Модули имеют немного другой способ работы. Также код, который я использовал с docs.microsoft.com/ en-us/azure/iot-edge/tutorial-csharp-module использует SendEventAsync(), тогда как вы используете SendMessageAsync() - person silent; 18.12.2017
comment
Да, я использовал код из документации в качестве отправной точки. SendMessageAsync — это мой метод, находящийся в созданном мной классе под названием IoTEdgeModule, чтобы я мог отправлять строки, и этот метод заботится о преобразовании строки в Message вместе с некоторой записью в консоль всякий раз, когда отправляется сообщение. Со временем у меня будет несколько модулей, которым нужно общаться друг с другом, поэтому размещение кода для подключения и отправки сообщений в общую библиотеку показалось мне правильной идеей. Я обновил свой пост, включив в него метод SendMessageAsync(). - person Aaron Prince; 18.12.2017
comment
Ok. Итак, вы можете проверить это, получив вместо этого DeviceClient из контекста? Просто чтобы посмотреть, может ли это быть проблемой. - person silent; 18.12.2017
comment
На самом деле у меня проблемы с получением сообщения на ModuleB, а не с отправкой их из ModuleB. Метод PipeMessage в исходном сообщении является получателем для ModuleB. ModuleA не имеет собственного PipeMessage, потому что он не принимает ввод в виде сообщений. Единственной обязанностью ModuleA является захват файлов и отправка сообщений. В этом сценарии для ModuleA нет userContext, потому что он будет передан из принимающей функции (например, PipeMessage). Поскольку ModuleA не нужно получать сообщения, у него нет файла userContext. - person Aaron Prince; 18.12.2017
comment
Кроме того, первое, что должен сделать PipeMessage, это Console.WriteLine. Когда ModuleB капризничает и больше не отвечает, он никогда не отправляет это: Message! - person Aaron Prince; 18.12.2017