[
https://issues.apache.org/jira/browse/CXF-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710351#action_12710351
]
Richard Opalka commented on CXF-2220:
-------------------------------------
I successfully verified the cxf2220.patch locally ;)
> Heavily reused "default" Work Queue Problem
> -------------------------------------------
>
> Key: CXF-2220
> URL: https://issues.apache.org/jira/browse/CXF-2220
> 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 integration.
> 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/OneWayProcessorInterceptor.java:
> .getAutomaticWorkQueue().execute(new Runnable() {
> rt/transports/http/src/main/java/org/apache/cxf/transport/http/HTTPConduit.java:
> queue = mgr.getAutomaticWorkQueue();
> rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/ContextUtils.java:
> : 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 side:
> When this "default" worker threads pool gets constructed all its worker
> threads have associated
> classloader of the calling thread (in our case calling thread has associated
> web application classloader).
> 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(SAAJInInterceptor.java:165)
> at
> org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:67)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:641)
> at org.apache.cxf.endpoint.ClientImpl$1$1.run(ClientImpl.java:722)
> at
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
> at org.apache.cxf.endpoint.ClientImpl$1.onMessage(ClientImpl.java:720)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2134)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream$1.run(HTTPConduit.java:2018)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
> at java.lang.Thread.run(Thread.java:595)
> 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:
> baseclassloa...@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(SAAJInInterceptor.java:84)
> at
> org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:96)
> ... 11 more
> To prevent these kinds of problems I had to implement the patches to don't
> reuse "default" worker threads pool.
> See attached HttpConduit.java 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() method.
> 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.
