Hi
It has been fixed :
http://svn.apache.org/viewvc?rev=909411&view=rev
I think many users do explicitly configure providers and if not then they do not see a continious growth (perhaps due to the same
threads coming in back) so noone has reported it yet...CC-ing to the users list so that users can explicitly register jaxb or
(default) json providers, which are the only two providers in the default list which have the contexts injected
thanks a million for spotting it.
Sergey
Hello,
I have built out a REST service that relies on the JAXBElementProvider for
writing the response. However, I didn't explicitly add the
JAXBElementProvider into provider configuration:
<jaxrs:server id="metaDataRestService" address="/">
<jaxrs:serviceBeans>
<ref bean="metaDataService" />
</jaxrs:serviceBeans>
<jaxrs:providers>
<ref bean="authenticationHandler" />
<ref bean="runtimeExceptionMapper" />
</jaxrs:providers>
</jaxrs:server>
I was relying on the ProviderFactory.SHARED_FACTORY for supplying the
JAXBElementProvider as the message writer. Everything functionally works
fine but occasionally encounter OOM exceptions with the heap dump clearly
pointing to large amounts of memory being held onto in the threadlocalproxy.
After further investigation, it looks to me like the SHARED_FACTORY never
registers its providers when they are used, so clearThreadLocalProxies are
NEVER called on them. If i explicitly add the JAXBElementProvider the issues
seems to have resolved the issue:
<bean id="jaxbProvider"
class="org.apache.cxf.jaxrs.provider.JAXBElementProvider" />
<jaxrs:server id="metaDataRestService" address="/">
<jaxrs:serviceBeans>
<ref bean="metaDataService" />
</jaxrs:serviceBeans>
<jaxrs:providers>
<ref bean="authenticationHandler" />
<ref bean="runtimeExceptionMapper" />
<ref bean="jaxbProvider" />
</jaxrs:providers>
</jaxrs:server>
Has anyone else had problems with this happening? Can someone more familiar
with the code base comment on this potential defect? It looks to me like
maybe a simple fix could be to make sure
handleMapper((List)candidates, ep, type, m);
even if the SHARED_FACTORY is used.
tags: threadlocal, threadlocalproxies, OutOfMemoryException, memory leak
--
View this message in context:
http://old.nabble.com/threadlocal-memory-leak-on-shared_factory--tp27555162p27555162.html
Sent from the cxf-dev mailing list archive at Nabble.com.
