cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <>
Subject [jira] Updated: (CXF-2220) Heavily reused "default" Work Queue Problem
Date Thu, 14 May 2009 17:20:45 GMT


Daniel Kulp updated CXF-2220:

    Attachment: cxf-2220.patch

I really don't think that switching to the Executors.newSingleThreadExecutor() is a good idea.
  It completely defeats the purpose of having the work queue.    I really think we SHOULD
be able to fix this in the AutomaticWorkQueueImpl.  

I've attached a patch (I'll probably commit to 2.2.x if tests pass with it) that does a bunch
of modifications to the AWQI:

1) Made it create it's own ThreadGroup - it tries to traverse up the parents of the current
thread group to find the highest parent that it can use.   Thus, the resulting threads should
be as close to "system" threads instead of application threads as possible.

2) Creates a ThreadFactory around that group.   It will set the contextClassLoader for each
thread it creates to the classloader of the AWQI, not any application context classloaders.

3) For each "Runnable" submitted to Execute, it wrappers it with a new Runnable that will
make sure the contextClassLoader on the thread used to run the runnable is the same as the
calling thread.    That should allow us to avoid modifying every place that something is submitted
to the AWQI to have it do the classloader copy.

I hope the combination of the three will fix the issue for you.   Could you give it a run
through with your tests and let me know how it goes?


> Heavily reused "default" Work Queue Problem
> -------------------------------------------
>                 Key: CXF-2220
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 2.2.1
>            Reporter: Richard Opalka
>            Assignee: Daniel Kulp
>         Attachments: cxf-2220.patch, HTTPConduit.diff
> Hi CXF Team,
>   We're fighting with threading+classloading related issues when testing JBossWS-CXF
> The problematic part is WorkQueueManagerImpl.getAutomaticWorkQueue() method that
> is reused in the following three places in CXF code base.
> [/home/opalka][/home/opalka/THIRDPARTY/CXF/SVN/tags/cxf-2.2.1]>grep -r getAutomaticWorkQueue
* | grep -v "\.svn" | grep -v Test | grep -v workqueue
> rt/core/src/main/java/org/apache/cxf/interceptor/   
            .getAutomaticWorkQueue().execute(new Runnable() {
> rt/transports/http/src/main/java/org/apache/cxf/transport/http/    
               queue = mgr.getAutomaticWorkQueue();
> rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/            
              :  workQueueManager.getAutomaticWorkQueue();
> This method constructs "default" worker threads pool on first request and this thread
pool is 
> heavily reused by CXF for other applications. We see the following problem on our server
> When this "default" worker threads pool gets constructed all its worker threads have
> classloader of the calling thread (in our case calling thread has associated web application
> This is how Java threads are constructed (they inherit the parent thread classloader).
> This thread pool is heavily reused by CXF for other applications.
> The problem will appear when we undeploy the web application (the one that worker threads
have associated
> classloader with). After undeployment of that archive all worker threads will throw ClassNotFoundException
when passed
> jobs will try to do something with the classloader. Here's the sample stack trace:
> 2009-05-12 09:30:14,923 INFO  [org.apache.cxf.phase.PhaseInterceptorChain:70] (pool-13-thread-2)
Interceptor has thrown exception, unwinding now
> org.apache.cxf.binding.soap.SoapFault: Problems creating SAAJ object model
> 	at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(
> 	at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(
> 	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
> 	at org.apache.cxf.endpoint.ClientImpl.onMessage(
> 	at org.apache.cxf.endpoint.ClientImpl$1$
> 	at org.apache.cxf.workqueue.SynchronousExecutor.execute(
> 	at org.apache.cxf.endpoint.ClientImpl$1.onMessage(
> 	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(
> 	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream$
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
> 	at java.util.concurrent.ThreadPoolExecutor$
> 	at
> Caused by: javax.xml.soap.SOAPException: Unable to create message factory for SOAP: Unable
to create SAAJ meta-factoryProvider com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl could
not be instantiated: java.lang.IllegalStateException: BaseClassLoader@298b744f{vfszip:/opt/svn/jbossas/tags/JBoss_5_0_1_GA/build/output/jboss-5.0.1.GA/server/cts/tmp/jsr88/WSAsyncHandler_wsservlet_vehicle.ear/WSAsyncHandler_wsservlet_vehicle_web.war/}
classLoader is not connected to a domain (probably undeployed?) for class com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl
> 	at javax.xml.soap.MessageFactory.newInstance(Unknown Source)
> 	at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.getFactory(
> 	at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(
> 	... 11 more
> To prevent these kinds of problems I had to implement the patches to don't reuse "default"
worker threads pool.
> See attached patch how to achieve that.
> Could you apply the patch for all three CXF souce files where "default" worker threads
pool is reused?
> The solution is to use e.g. Executors.newSingleThreadExecutor() instead of WorkQueueManagerImpl.getAutomaticWorkQueue()
> Thanks,
> JBossWS Team
> PS: BTW, it took many hours of heavy debugging to identify this issue :(

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message