[
https://issues.apache.org/jira/browse/OLINGO-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14910151#comment-14910151
]
Christian Amend commented on OLINGO-754:
----------------------------------------
Hi,
we could implement a tearDown method which is called after all our processing
is done. The question would be where to put this method. The scenario service
factory is a good place imho.
Another open point in my opinion are the parameters which we pass to this
tearDown method. If I want to truly call this method after all our processing
is done I don`t have access to the ODataContext anymore. So would this still
fit your use case if you had to cache the ODataContext inside your
ServiceFactory so that if a teardown is called you can close all open
operations?
Also a fix like this is not trivial. We would have to make sure that even in
exception cases this teardown method is called correctly.
WDYT?
Best Regards,
Christian
> MemoryLeak when using Olingo in Wildfly
> ---------------------------------------
>
> Key: OLINGO-754
> URL: https://issues.apache.org/jira/browse/OLINGO-754
> Project: Olingo
> Issue Type: Bug
> Components: odata2-jpa
> Affects Versions: V2 2.0.4
> Environment: java 8, wildfly 8.2, Linux
> Reporter: Manuel Blechschmidt
>
> The following code produces a memory leak in an application server:
> {code:title=org.apache.olingo.odata2.jpa.processor.core.ODataJPAContextImpl}
> @Override
> public void setODataContext(final ODataContext ctx) {
> odataContext = ctx;
> // This produces a memory leak on wildfly
> setContextInThreadLocal(odataContext);
> }
> {code}
> I removed the setContextInThreadLocal and it worked afterwards. I searched
> the whole code how this variable is normaly removed but was not able to find
> the clean way to solve this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
