NServiceBus: задержка обработки всех входящих сообщений - PullRequest
0 голосов
/ 04 декабря 2018

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

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

В данный момент мы разработчики делаем это, потому что мы запускаемСтроитель вручную, ad hoc;мы буквально останавливаем службу Feeder, когда собираемся запустить Builder, а затем перезапускаем его.Теперь, когда мы собираемся запустить Builder по расписанию, нам нужно автоматизировать этот процесс.

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

Есть ли в NServiceBus функция, которая может выполнить это для нас?Первоначально я думал о планировании сообщений или тайм-аутах, но они были специально настроены конечной точкой отправка .Мне нужно тайм-аут сообщений на принимающей конечной точке.

1 Ответ

0 голосов
/ 14 декабря 2018

Похоже, что относительно простым ответом на этот вопрос будет проверка на наличие проблем параллелизма, поэтому, когда фидер отправляется на фиксацию в базе данных, он должен проверить, что строка данных все еще находится в том же состоянии, что и при первом ее чтении.иначе выведите ошибку параллелизма.Затем NServiceBus сможет повторить попытку после этого случая.Посмотрите на эту ссылку, и она объяснит немного более подробно, поскольку кажется, что вам может понадобиться оптимистическая стратегия блокировки.http://www.agiledata.org/essays/concurrencyControl.html

...