cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Opalka (JIRA)" <>
Subject [jira] Updated: (CXF-2220) Heavily reused "default" Work Queue Problem
Date Thu, 14 May 2009 15:40:46 GMT


Richard Opalka updated CXF-2220:

    Attachment:     (was: patch.diff)

> Heavily reused "default" Work Queue Problem
> -------------------------------------------
>                 Key: CXF-2220
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 2.2.1
>            Reporter: Richard Opalka
>         Attachments: 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