[
https://issues.apache.org/jira/browse/CAMEL-17588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17504969#comment-17504969
]
Björn Ohm edited comment on CAMEL-17588 at 3/11/22, 3:23 PM:
-------------------------------------------------------------
I knew from other situtions, where ThreadLocals are used, that they are cleaned
up right after use (each time) in the current thread, typacilly in a
finally-block (or similiar) and recreated new each time (I think this is the
recommended way to handle ThreadLocals). I don't know, if this could be another
approach (desired and possible).
Your fix seems to be a one-time-cleanup while shutdown.
I tested it locally with my application and basically it worked (no more
SEVERE-logs). But a problem could be, that the used {_}threads{_}-Map could
grow unbounded over the time??
I have attached a small Camel-Spring-Boot-App [^plain-camel.zip], which started
a CXF-Endpoint. After you post some SOAP-Requests, you can see in
org.apache.camel.impl.engine.DefaultReactiveExecutor#workers the
ThreadLocals... (see {_}/plain-camel/.readme{_}).
Theres is also a UnitTest, which do this for you
({_}plain.camel.PlainCamelApplicationTest.callService(){_}).
Of course this is just the case for incoming http-threads. I don't know in
which cases the reactive-engine is used. For example we use JMS-Consumer with a
thread-pool (growing and shrinking)...
!workers-threadLocals.PNG|width=268,height=226!
was (Author: JIRAUSER284590):
I knew from other situtions, where ThreadLocals are used, that they are cleaned
up right after use (each time) in the current thread, typacilly in a
finally-block (or similiar) and recreated new each time (I think this is the
recommended way to handle ThreadLocals). I don't know, if this could be another
approach (desired and possible).
Your fix seems to be a one-time-cleanup while shutdown.
I tested it locally with my application and basically it worked (no more
SEVERE-logs). But a problem could be, that the used {_}threads{_}-Map could
grow unbounded over the time??
I have attached a small Camel-Spring-Boot-App, which started a CXF-Endpoint.
After you post some SOAP-Requests, you can see in
org.apache.camel.impl.engine.DefaultReactiveExecutor#workers the
ThreadLocals... (see {_}/plain-camel/.readme{_}).
Theres is also a UnitTest, which do this for you
({_}plain.camel.PlainCamelApplicationTest.callService(){_}).
Of course this is just the case for incoming http-threads. I don't know in
which cases the reactive-engine is used. For example we use JMS-Consumer with a
thread-pool (growing and shrinking)...
!workers-threadLocals.PNG|width=268,height=226!
> Missing Clean-Up for DefaultReactiveExecutor.Worker-ThreadLocals
> ----------------------------------------------------------------
>
> Key: CAMEL-17588
> URL: https://issues.apache.org/jira/browse/CAMEL-17588
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 3.14.1
> Reporter: Björn Ohm
> Priority: Minor
> Fix For: 3.17.0
>
> Attachments: catalina.out, plain-camel.zip, workers-threadLocals.PNG
>
>
> We are running a Camel-Application on a Tomcat. While the Tomcat-Shutdown we
> observed a bunch of Thread-Local-WARNINGS in the catalina.out like:
> {code:java}
> 02-Feb-2022 01:31:23.810 SCHWERWIEGEND [main]
> org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks
> The web application [provinzial-integration-intern] created a ThreadLocal
> with key of type [java.lang.ThreadLocal.SuppliedThreadLocal] (value
> [java.lang.ThreadLocal$SuppliedThreadLocal@4a4357f5]) and a value of type
> [org.apache.camel.impl.engine.DefaultReactiveExecutor.Worker] (value
> [org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker@76e66f23]) but
> failed to remove it when the web application was stopped. Threads are going
> to be renewed over time to try and avoid a probable memory leak.{code}
> Obviously this belongs to the ThreadLocals used in
> {_}org.apache.camel.impl.engine.DefaultReactiveExecutor{_}.
> In the worst case, this can lead to memory problems.
> The ThreadLocals should be cleaned up.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
