Camel Split EIP和池中線程的使用似乎沒有超過最小線程

Question

我正在使用Apache Camel 2.15並發現了一個有趣的行為。 我將通過REST API調用接收的數據放入作為直接端點的Camel路由中。 該路由依次使用拆分EIP並調用另一個也是直接端點的Camel路由。

以下是相關的Camel代碼

from("direct:activationInputChannel").routeId("cbr_activation_route")
// removed some processes
.split(simple("${body}"))
   .parallelProcessing()
   .to("direct:activationItemEndPoint")
.end()
// removed some processes

和

from("direct:activationItemEndPoint").routeId("cbr_activation_item_route")
.process(exchange -> this.doSomething(exchange))
// removed some processes

使用直接端點應該使調用同步並在同一個線程上運行。 正如預期的那樣，split / parallelProcessing用法導致第二個路由在單獨的線程上運行。 拆分器使用默認線程池。

當我使用jMeter對應用程序運行一些負載測試時，我發現拆分路徑正成為瓶頸。 通過使用200個線程的負載測試，我觀察到Tomcat http線程池在jConsole中具有200的currentThreadCount 。 我還觀察到Camel路由cbr_activation_route有200個ExchangesInflight 。

問題是cbr_activation_item_route只有50個ExchangesInflight 。 數字50對應於為默認池設置的poolSize 。 maxPoolSize設置為500， maxQueueSize設置為1000（默認值）。

此路線的機上交換次數從未超過最小池大小。 即使有大量的請求排隊並且線程可用。 當我將Camel默認線程池中的poolSize更改為200時， cbr_activation_item_route使用了新的最小值並且有200個ExchangesInflight 。 似乎Camel不會使用比最小線程更多的線程，即使有更多線程可用，即使在負載下也是如此。

是否有可能導致此行為的設置或某些內容？ 當最小值設置為50時，為什么Camel在第一次測試運行中不會使用200個線程？

謝謝

Answer 1

同意Frederico關於Java線程池執行器行為的回答。 它更喜歡向隊列添加新請求，而不是在達到'corePoolSize'線程后創建更多線程。

如果你希望你的TPE在達到'corePoolSize'之后進入請求時添加更多線程，那么基於Java調用BlockingQueue中的offer（）方法對請求進行排隊這一事實，實現這一點有一種輕微的方法。 如果offer（）方法返回false，它將創建一個新線程並調用Executor的rejectedExecutionHandler。 可以覆蓋offer（）方法並創建自己的ThreadPool執行器版本，該版本可以根據負載擴展線程數。

我在這里找到了一個例子： https ： //github.com/kimchy/kimchy.github.com/blob/master/_posts/2008-11-23-juc-executorservice-gotcha.textile

Answer 2

這是預期的行為。 這與Camel本身無關，但與Java的ThreadPoolExecutor有關。

如果您閱讀了鏈接的文檔，那么它會說：

如果有多個corePoolSize但運行的maximumPoolSize線程少於maximumPoolSize，則只有在隊列已滿時才會創建新線程。

如果將maxQueueSize設置為1000，則必須在創建新線程之前創建1050個請求，最多200個。如果您不希望將請求排隊，請嘗試告訴Camel使用SynchronousQueue （不建議使用，恕我直言）。