将项目从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线程上启动作为测试运行时。在以前的版本中，测试还以各自的线程启动了容器。
对为什么测试现在表现有所不同的任何见解？还是有一种方法可以配置它以使它们脱离主线程？
答案 0 :(得分：4)
将容器属性missingQueuesFatal设置为false。
请参见Spring for Apacher Kafka 2.2. What's new。
已添加新的容器属性（missingTopicsFatal）。有关更多信息，请参见使用KafkaMessageListenerContainer。
从2.2版开始，添加了一个名为missingTopicsFatal的新容器属性（默认值：true）。如果代理中没有任何已配置的主题，这将阻止容器启动。如果容器配置为侦听主题模式（正则表达式），则该方法不适用。以前，容器线程在consumer.poll（）方法内循环，等待主题出现，同时记录许多消息。除了日志，没有迹象表明存在问题。要恢复以前的行为，可以将属性设置为false。
将该属性设置为false会禁用该检查。
答案 1 :(得分：0)
使用弹簧靴（例如2.2.2.RELEASE），您可以使用：
spring.kafka.listener.missing-topics-fatal=false
，它将使应用程序继续运行，但不会收到缺少主题的消息。如果在添加主题之后，则必须重新启动该应用程序，以便使用者接收消息。