[
https://issues.apache.org/jira/browse/CAMEL-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012874#comment-13012874
]
Marcin Kolda commented on CAMEL-3813:
-------------------------------------
I prepared such testcase to verify that ThreadLocal is empty right after
evaluation (without using UnitOfWork and Synchronization). It's done this way
in {{public <T> T evaluate(CamelContext context, Object body, Class<T> type)}}
and few other methods in XPathBuilder. Such solution would be just simpler for
me.
I tested this with our real system previously and that still didn't work for
us. I will have to digg into this when I'll have more time. I'll let you know
if I find anything.
> XPathBuilder doesn't clear ThreadLocal with exchange after evaluation
> ---------------------------------------------------------------------
>
> Key: CAMEL-3813
> URL: https://issues.apache.org/jira/browse/CAMEL-3813
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Affects Versions: 2.7.0
> Reporter: Marcin Kolda
> Assignee: Claus Ibsen
> Priority: Minor
> Labels: xpath
> Fix For: 2.8.0
>
> Attachments: bug_reproduction.patch
>
>
> XPathBuilder doesn't clear ThreadLocal with exchange (and variableResolver)
> after evaluation. In such case reference to current exchange (and body,
> headers, properties, etc.) remains in Thread until current thread dies or
> evaluates new exchange with the same XPathBuilder instance.
> The result of this is that each thread can contain references to multiple
> exchanges (up to the number of xpaths in camel context), that can't be
> collected by GC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
