Multithreading Apache Camel Jetty组件线程在测试期间不会停止(自定义minThreads maxThreads)

Multithreading Apache Camel Jetty组件线程在测试期间不会停止(自定义minThreads maxThreads),multithreading,spring-boot,testing,apache-camel,jetty-9,Multithreading,Spring Boot,Testing,Apache Camel,Jetty 9,我们有一个带有ApacheCamel的Spring引导应用程序。我们在application.yml中公开了minThreads/maxThreads jetty: max-threads: ${JETTY_MAX_THREADS:200} min-threads: ${JETTY_MIN_THREADS:8} enable-jmx: ${JETTY_ENABLE_JMX:false} 我们的测试使用junit jupiter,注释如下: @ActivePr

我们有一个带有ApacheCamel的Spring引导应用程序。我们在application.yml中公开了minThreads/maxThreads

jetty:
      max-threads: ${JETTY_MAX_THREADS:200}
      min-threads: ${JETTY_MIN_THREADS:8}
      enable-jmx: ${JETTY_ENABLE_JMX:false}
我们的测试使用junit jupiter,注释如下:

@ActiveProfiles("test")
@CamelSpringBootTest
@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)
@MockEndpoints
每个测试都会使用几个从Jetty端点开始的路由加载camelContext(每个测试大约5个路由/10个测试/10个类)。因此,总的来说,每个测试大约从5*8=40个线程开始。在暴露最小/最大线程之前,一切正常。当他们暴露时,发生了以下情况:

java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached
    at java.base/java.lang.Thread.start0(Native Method)
    at java.base/java.lang.Thread.start(Thread.java:803)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.startThread(QueuedThreadPool.java:660)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.ensureThreads(QueuedThreadPool.java:642)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.doStart(QueuedThreadPool.java:182)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
    at org.apache.camel.component.jetty.JettyHttpComponent.createServer(JettyHttpComponent.java:1265)
    at org.apache.camel.component.jetty.JettyHttpComponent.connect(JettyHttpComponent.java:325)
    at org.apache.camel.http.common.HttpCommonEndpoint.connect(HttpCommonEndpoint.java:187)
    at org.apache.camel.http.common.HttpConsumer.doStart(HttpConsumer.java:58)
在彻底调查之后,我们注意到,即使上下文被停止,线程(CamelJettyServer)也无法这样做。还有一些线程处于等待状态(尽管接受线程已停止)。在下面的屏幕截图中,我们可以看到至少5个孤立线程(没有指向接受线程的链接)

我们使用默认配置(没有min/maxThreads)重新运行测试,这些QueuedThreadPool线程被正确终止

原因似乎是父“AbstractLifeCycle”类的一个名为“\u stopTimeout”的属性。在设置min/maxThreads时,\ u stopTimeout设置为5000,而在使用默认配置时,此设置为30000。我们无法理解为什么会发生这种情况,因为两种情况下执行的代码似乎完全相同。此外,我们无法找到如何公开和配置此“\u stopTimeout”。这可能不会对生产环境产生影响,但在测试问题解决之前,我们无法在生产中使用它们。有办法解决这个问题吗