You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cxf.apache.org by colinmarsh <co...@gmail.com> on 2010/02/11 22:37:29 UTC

threadlocal leak on shared_factory?

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.
-- 
View this message in context: http://old.nabble.com/threadlocal-leak-on-shared_factory--tp27555162p27555162.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: Error calling webservice!Please Help!

Posted by Eoghan Glynn <eo...@gmail.com>.

You've rebuilt with the new method, but are you sure that the old class
isn't lurking around somewhere?

Have you restarted everything so nothing is lurking in memory?

Reinstalled everything cleanly so you're sure that an old version of the
built artefacts isn't being picked up in error?

/Eoghan



On 7 February 2010 21:48, Wadi Jalil Maluf <wa...@gmail.com> wrote:

> Hi all,
> I get the following error calling the webservice from flex:
> java.lang.NullPointerException
>      at
> org.apache.cxf.frontend.SimpleMethodDispatcher.getMethod(SimpleMethodDispatcher.java:96)
>
>      at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:57)
>
>      at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
>
>      at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
>      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>      at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>      at
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
>
>      at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:98)
>
>      at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
>
> This happends when I call a new method recently added to my webservices.I
> rebuild with all possible forms, but still happends.
> Does anyone know why?is it a Apache cxf bug, netbeans Bug or something?
> Any help would be appreciated,
> Regards
>
>
> __________ Información de ESET Smart Security, versión de la base de firmas
> de virus 4933 (20100310) __________
>
> ESET Smart Security ha comprobado este mensaje.
>
> http://www.eset.com
>
>
>

RE: Error calling webservice!Please Help!

Posted by Ron Grimes <rg...@sinclairoil.com>.

My architecture includes CXF with Flex on the front-end. So, this sounds to  me like something I've seen numerous times. It sounds to me like your Flex app is calling the new service operation, but CXF can't find it. This is usually a situation wherein your Tomcat (or whatever container you are using) is still only aware of the previous version of your deployment. If you are using Tomcat, shut it down, clear the copies of your deployment out of the temp folder, redeploy the new copy of the war, restart Tomcat. Also, try calling up the WSDL from a browser address bar, or whatever tool you want, and make sure the current working copy of the wsdl contains your new operation. Then, all should be good to go.

R.  Grimes

-----Original Message-----
From: Wadi Jalil Maluf [mailto:wadijm@gmail.com] 
Sent: Sunday, February 07, 2010 2:49 PM
To: users@cxf.apache.org
Subject: Error calling webservice!Please Help!

Hi all,
I get the following error calling the webservice from flex:
java.lang.NullPointerException
       at 
org.apache.cxf.frontend.SimpleMethodDispatcher.getMethod(SimpleMethodDispatcher.java:96) 

       at 
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:57) 

       at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58) 

       at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
       at 
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
       at java.util.concurrent.FutureTask.run(FutureTask.java:138)
       at 
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) 

       at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:98) 

       at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236) 

This happends when I call a new method recently added to my 
webservices.I rebuild with all possible forms, but still happends.
Does anyone know why?is it a Apache cxf bug, netbeans Bug or something?
Any help would be appreciated,
Regards

__________ Información de ESET Smart Security, versión de la base de firmas de virus 4933 (20100310) __________

ESET Smart Security ha comprobado este mensaje.

http://www.eset.com

Error calling webservice!Please Help!

Posted by Wadi Jalil Maluf <wa...@gmail.com>.

Hi all,
I get the following error calling the webservice from flex:
java.lang.NullPointerException
       at 
org.apache.cxf.frontend.SimpleMethodDispatcher.getMethod(SimpleMethodDispatcher.java:96) 

       at 
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:57) 

       at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58) 

       at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
       at 
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
       at java.util.concurrent.FutureTask.run(FutureTask.java:138)
       at 
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) 

       at 
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:98) 

       at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236) 

This happends when I call a new method recently added to my 
webservices.I rebuild with all possible forms, but still happends.
Does anyone know why?is it a Apache cxf bug, netbeans Bug or something?
Any help would be appreciated,
Regards


__________ Información de ESET Smart Security, versión de la base de firmas de virus 4933 (20100310) __________

ESET Smart Security ha comprobado este mensaje.

http://www.eset.com

Re: threadlocal memory leak on shared_factory?

Posted by Sergey Beryozkin <sb...@progress.com>.

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.

Re: threadlocal memory leak on shared_factory?

Posted by Sergey Beryozkin <sb...@progress.com>.

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.