Cuando se actualiza un proyecto de Springboot 2,0 a 2,1, también pasaron spring-kafka-integrationdesde 3.0.1 a 3.2.1. De este modo, nuestras pruebas ahora todo no se inician debido a:
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
Los ordenadores de desarrollo no tienen un Kafka se ejecutan localmente, y las pruebas que utilizan un EmbeddedKafkaBrokerlo hacen con una extensión JUnit5 a medida que se detiene / inicia los oyentes de contenedores entre las pruebas (mientras se busca todas las particiones y los temas a más tardar, para evitar pruebas accidentalmente fugas mensajes de romper expectativas en las pruebas posteriores). Aunque mucho más rápido que @DirtiesContext, no inyecta sí mismo en el contexto durante la configuración como la @EmbddedKafkaanotación hace.
En la versión anterior, esto no era un problema; Nos gustaría ver algunos mensajes de registro por no ser capaz de conectarse mientras que la extensión configurado e iniciado el corredor, pero entonces todo estaba bien.
En la nueva versión del contexto no se puede iniciar por completo (la extensión personalizada ni siquiera tiene la oportunidad de correr). En cuanto a las propiedades, el fallo de arranque puedo ver alrededor de ajuste de sólo es spring.kafka.admin.fail-fast, pero eso es FALSO por defecto y que no lo cambie.
Comparándolo con poner en marcha el proyecto en sí mismo como una aplicación springboot, la primera diferencia que veo es que los contenedores se inician en sus propios hilos cuando se ejecuta como una aplicación, pero en la main/ Test Workerel hilo cuando se ejecuta como una prueba. En la versión anterior, las pruebas también comenzaron los contenedores en su propio hilo.
Cualquier idea de por qué las pruebas se comportan de manera diferente ahora? O si hay una manera de configurarlo para conseguir que el hilo principal?
Establecer la propiedad de contenedores missingQueuesFatala false.
Ver la primavera de Apacher Kafka 2.2. ¿Qué hay de nuevo .
Una nueva propiedad recipiente (missingTopicsFatal) ha sido añadido. Consulte Uso KafkaMessageListenerContainer para más información.
A partir de la versión 2.2, una nueva propiedad contenedor llamado missingTopicsFatal ha sido añadido (por defecto: true). Esto evita que el contenedor de arranque si cualquiera de los temas configurados no están presentes en el corredor. No se aplica si el contenedor está configurado para escuchar a un patrón tema (expresiones regulares). Anteriormente, las hebras de contenedor en bucle dentro del método de espera consumer.poll () para el tema que aparecen mientras se registran muchos mensajes. Aparte de los registros, no había ninguna indicación de que no fue un problema. Para restaurar el comportamiento anterior, se puede establecer la propiedad en false.
Al establecer la propiedad a los falsos deshabilita la comprobación.