Spring Dataflow Перенос сообщений с одного Rabbit VHost на другой - PullRequest
0 голосов
/ 20 мая 2019

TLDR: Не получается передать сообщения от одного RabbitMQ VHost другому RabbitMQ VHost.

У меня возникла проблема с Spring Cloud Dataflow, когда выясняется, что, несмотря на указание различных VHosts RabbitMQ для источника и приемника, они никогда не попадают в целевой Exchange.

Мой поток данных выглядит следующим образом: RabbitMQ Source | CustomProcessor | RabbitMQ Sink

RabbitMQ Source читает из очереди на vHostA и RabbitMQ Sink должен выводить в ExchangeBlah на vHostB.

Однако в ExchangeBlah на vHostB сообщения не попадают, и в журнале RabbitMQ Sink появляются ошибки:

Отключение канала: ошибка канала; Метод протокола: 'метод (код ответа = 404, текст ответа = NOT_FOUND - нет обмена' ExchangeBlah 'в vhost' vHostA ', идентификатор класса = 60, идентификатор метода = 40)

У меня такое ощущение, что это может быть связано с переменной среды Spring

spring.cloud.dataflow.applicationProperties.stream.spring.rabbitmq.virtual-хост = vhostA

Поскольку поток данных использует очереди в качестве связи между различными этапами потока, если я не укажу этот параметр, то исходные и приемные очереди связи RabbitMQ создаются на виртуальных хостах, указанных в их соответствующих конфигурациях, однако очереди связи нет создан для CustomProcessor. Поэтому данные застряли в очереди связи с источником.

Кроме того, я знаю, что по возможности Shovels могут обойти это, но похоже, что вам доступна опция вывода в другой VHost в приемнике RabbitMQ, тогда должно работать.

Скорее всего, это может быть ошибка в приложениях Rabbit Stream Source / Sink.

UPDATE: Если посмотреть на определение потока (после его развертывания), переключатель spring.rabbitmq.virtual-host определяется дважды. Один раз с vHostB, который определен для приемника, а затем с vHostA, который является свойством Spring.

Удаление свойства приложения виртуального хоста и явная установка spring.rabbitmq.virtual-host, host, имени пользователя и пароля на процессоре (включая источник и приемники RabbitMQ), и он попадает в очередь связи с процессором, но как приемник RabbitMQ настроен на другой VHost, похоже, он не идет дальше.

В этом сценарии очереди связи, которые создаются между различными этапами потока, создаются на том же VHost, с которого читает источник (vHostA). Поскольку мы можем передать приложениям параметр spring.rabbitmq.virtual-host только один раз, приемник не знает, как просматривать очереди связи, чтобы передать эти данные в целевой обмен на vHost B.

Это почти как если бы отсутствовали переключатели на Source и Sink RabbitMQs, или я пропустил общую настройку, которая определяет VHost того, где должны находиться очереди связи, без переопределения исходного и целевого VHosts на источнике и приемниках RabbitMQ

1 Ответ

2 голосов
/ 20 мая 2019

Обратите внимание, что SCDF не связывается напрямую с RabbitMQ. SCDF пытается автоматизировать создание «env-vars» Spring Cloud Stream на основе четко определенных соглашений об именах, полученных на основе потоков и имен приложений.

Сами приложения подключаются для публикации / подписки на биржи RabbitMQ независимо друг от друга. Поскольку правильные «env-vars» оказываются свойствами приложений при их начальной загрузке, они должны иметь возможность подключаться согласно конфигурации.

Вы указали spring.cloud.dataflow.applicationProperties.stream.spring.rabbitmq.virtual-host=vhostA свойство. При наличии SCDF пытается распространить это как от virtual-host до всех потоковых приложений, которые он развертывает на целевой платформе.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...