David Benes created CAMEL-21813:
-----------------------------------
Summary: Threads from producer template when using InOut with
ActiveMQ are not being closed
Key: CAMEL-21813
URL: https://issues.apache.org/jira/browse/CAMEL-21813
Project: Camel
Issue Type: Bug
Components: came-jms
Affects Versions: 4.10.0, 4.7.0, 4.6.0
Environment: ActiveMQ 5.18.3
Java 17
Reporter: David Benes
Attachments: camel-left-threads.zip
When using ProducerTemplate and sending data to ActiveMQ with InOut exchange
pattern it opens a 2 threads that are still there even when response is
returned and producer template is closed.
Thread names are:
# TemporaryQueueReplyManager
# JmsReplyManagerTimeoutChecker
If you are using this pattern to handle some requests over the time number of
threads accumulates up to the number of allowed threds in the pool (if using a
pool, defaults to ~1000 for ActiveMQ) and no more messages are being sent.
Application has to be restarted.
Example that replicates the problem is attached. Requirements to run the
example is having ActiveMQ running on localhost. Example is a simple Maven
project. It contains single file that includes `main` method that replicates
the problem.
This example sends messages into ActiveMQ queue in InOut exchange pattern. And
another Processor is replying with slight delay.
When executed in debug mode, you will see that number of threads is only
increasing. Also it prints to standard out number of threds at the beginning
and in the end. At the end there is at least 2 times more threads still running
as the number of messages that were send.
It behaves the same when using connection pool or not. Verified that it behaves
the same with several versions of Apache Camel.
The only way found how to let those threads finish is sending the message in
InOnly exchange pattern. But that is not usable as a workaround as we would not
get necessary response.
Is there something that we are doing wrong when closing the producer? As it is
documented that you should close the producer template and we are doing exactly
that, it looks like a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
