Тесты Spring Integration Kafka 3.0.1 -> 3.1.2 теперь не запускаются, если при запуске нет доступного брокера - PullRequest
Новая
       14

Тесты Spring Integration Kafka 3.0.1 -> 3.1.2 теперь не запускаются, если при запуске нет доступного брокера

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

При обновлении проекта с Springboot 2.0 до 2.1 мы также обновили spring-kafka-integration с 3.0.1 до 3.2.1.При этом все наши тесты теперь не запускаются из-за: 

org.apache.kafka.clients.NetworkClient   : [Consumer clientId=consumer-1, groupId=x] Connection to node -1 could not be established. Broker may not be available.
org.apache.kafka.clients.NetworkClient   : [Consumer clientId=consumer-1, groupId=x] Connection to node -1 could not be established. Broker may not be available.
org.apache.kafka.clients.NetworkClient   : [Consumer clientId=consumer-1, groupId=x] Connection to node -1 could not be established. Broker may not be available.
...
org.springframework.context.ApplicationContextException: Failed to start bean 'eventInboundFlow.kafka:message-driven-channel-adapter#0'; nested exception is org.apache.kafka.common.errors.TimeoutException: Timeout expired while fetching topic metadata

На наших сборочных машинах не работает Kafka локально, а тесты, использующие EmbeddedKafkaBroker, делают это с пользовательским расширением JUnit5, котороеостанавливает / запускает прослушиватели контейнеров между тестами (при поиске всех разделов и тем до последних, чтобы предотвратить случайную утечку тестов сообщениями, чтобы сломать ожидания в последующих тестах).Хотя он намного быстрее, чем @DirtiesContext, он не внедряется в контекст во время настройки, как это делает аннотация @EmbddedKafka.

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

В новой версии контекст не запускается полностью (пользовательское расширение даже не получаетшанс побежать).Глядя на свойства, единственная настройка, которую я вижу при сбое запуска, это spring.kafka.admin.fail-fast, но по умолчанию это FALSE, и мы его не меняем.

Сравнивая его с запуском самого проекта в виде приложения Springboot, первое отличие, которое я вижу, состоит в том, что контейнеры запускаются в своих собственных потоках при запуске в качестве приложения, но в потоке main / Test Worker, когдазапустить в качестве теста.В предыдущей версии тесты также запускали контейнеры в своем собственном потоке.

Любое понимание того, почему тесты ведут себя иначе?Или, если есть способ настроить его, чтобы отключить их от основного потока?

1 Ответ

4 голосов
/ 04 мая 2019

Установите свойство контейнера missingQueuesFatal на false.

См. Spring для Apacher Kafka 2.2. Что нового .

Добавлено новое свойство контейнера (missingTopicsFatal). См. Использование KafkaMessageListenerContainer для получения дополнительной информации.

Начиная с версии 2.2, было добавлено новое свойство контейнера с именем missingTopicsFatal (по умолчанию: true). Это предотвращает запуск контейнера, если какие-либо из настроенных тем отсутствуют в посреднике. Он не применяется, если контейнер настроен на прослушивание шаблона темы (регулярное выражение). Ранее потоки контейнера зацикливались в методе consumer.poll (), ожидая появления темы при регистрации большого количества сообщений. Помимо журналов не было никаких признаков того, что возникла проблема. Чтобы восстановить предыдущее поведение, вы можете установить для свойства значение false.

Установка свойства в false отключает проверку.

...