camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Avnish Pundir <>
Subject sjms creating too many unnecessary threadpools and proposal for fixing it
Date Fri, 16 Dec 2016 10:51:22 GMT
In my spring+camel integration application we are using SJMS 
extensively. There are more than 100 producers and more than 50 
consumers that we have in our application. Recently I started 
discovering the usage of threads and noticed from JMX console there are 
way toooo many threadpools most of which are SJMS.

All our SJMS consumers are transacted thus we are processing all 
messages synchronously using the artemis consumer thread. Further 
digging down in the SjmsConsumer I found that the executor threadpool is 
created even if this endpoint (thus consumer) is configured for 
synchronous processing. Further dig down in the code confirms that 
SjmsConsumer itself doesn't uses this executor and it's passed to 
InOnlyMessageHandler or InOutMessageHandler -- both of which do not use 
this executor if the processing is to have transaction support 
(isTransacted()) or configured for synchronous processing 
(isSynchronous()). This essentially means that with each new 
SjmsConsumer, a new ThreadPoolExecutor object is created which is never 
used for transacted or synchronous consumers.

Although all these ThreadPoolExecutor do not have any threads in their 
pool since this is never used (PoolSize is confirmed to 0 all the times 
from JMX for these pools) but seeing so many threadpool objects itself 
made me uncomfortable in first spot. It's only after this much digging 
that I figured out that it's only ThreadPoolExecutor object without any 
active thread which we have in our application.

IMHO, it makes sense to enhance SjmsConsumer to skip creation of this 
executor in doStart method if it's transacted or synchronous consumer. I 
can see "if (this.executor != null)" checks in SjmsConsumer already 
(e.g. doStop method) thus this should not impact the flow in any way 
(may be we'll have to add few more checks like this).

If core developer agrees, I can take up this enhancements with a new 
pull request.

(My another objective is to dynamically increase/decrease consumer count 
for SJMS consumer, however that I'll take up in a separate thread).

*Avnish Pundir*

Disclaimer: The information contained in this communication is 
confidential, private, proprietary, or otherwise privileged and is intended 
only for the use of the addressee.Unauthorized use, disclosure, 
distribution or copying is strictly prohibited and may be unlawful. If you 
have received this communication in error, please delete this message and 
notify the sender immediately - Samin TekMindz India Pvt.Ltd. 

View raw message