Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Message-ID: <1918587730.1242315646160.JavaMail.jira@brutus>
Date: Thu, 14 May 2009 08:40:46 -0700 (PDT)
From: "Richard Opalka (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Subject: [jira] Updated: (CXF-2220) Heavily reused "default" Work Queue
 Problem
In-Reply-To: <1715825434.1242315407029.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CXF-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated CXF-2220:
--------------------------------

    Attachment:     (was: patch.diff)

> 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
>         Attachments: 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: 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(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.