Yea. We found this two weeks ago. The latest snapshot builds have this fixed. Can you try the latest snapshots to make sure it does fix it for you.
Dan On Mon June 29 2009 9:45:08 am wytas wrote: > Despite all my efforts to find the solution for my problem with > asynchronous calls and RejectedExecutionException i haven't, so i'm hoping > for some help here. > > So... Recently i got java.util.concurrent.RejectedExecutionException when > WS client sends a lot of async requests. According to stacktrace it happens > in: > > java.util.concurrent.RejectedExecutionException > at > java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(Threa >dPoolExecutor.java:1477) at > java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384) > at > java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:867 >) at > org.apache.cxf.workqueue.AutomaticWorkQueueImpl.execute(AutomaticWorkQueueI >mpl.java:249) at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRespons >e(HTTPConduit.java:2035) at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPCon >duit.java:1940) at > org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputSt >ream.java:47) at > org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:180) at > org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66) at > org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:627) at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInte >rceptor.handleMessage(MessageSenderInterceptor.java:62) at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai >n.java:236) at > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:411) > > This happens when there in no room for one more thread in > ThreadPoolExecutorear's queue - exactly as JRE javadoc says: > RejectedExecutionException - at discretion of RejectedExecutionHandler, if > task cannot be accepted for execution. As i see from CXF code > AutomaticWorkQueueImpl (which extends ThreadPoolExecutor) doesn't specify > any RejectedExecutionHandler at creation time and gets constructed with > default handler which happens to be > java.util.concurrent.ThdPoolExecutor.AbortPolicy. In such case > RejectedExecutionException is thrown when work queue gets exhausted. > > The problem is that i can't catch exception and retry the WS call as these > threads are created to handle the response while request is already sent > (and processed - only the response is lost). The only logical place to > handle this situation seems to be my custom RejectedExecutionHandler. > Despite all my efforts to find the way to specify some other > RejectedExecutionHandler than default one i failed... > > Maybe someone has already got the solution or could guide to me to it? -- Daniel Kulp [email protected] http://www.dankulp.com/blog
