Actually, one thing I forgot to mention as a possibility.... You CAN configure a new "default" workqueue in your CXF config that would specify a different handler as well as a larger queue and more threads. If you create a spring bean of type org.apache.cxf.workqueue.AutomaticWorkQueueImpl and give it a "name" property of "default", you should be able to configure it to work for you. I haven't completely tried it though.
Dan On Mon June 29 2009 10:16:05 am Daniel Kulp wrote: > 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(Thr > >ea dPoolExecutor.java:1477) at > > java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:38 > >4) at > > java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:8 > >67 ) at > > org.apache.cxf.workqueue.AutomaticWorkQueueImpl.execute(AutomaticWorkQueu > >eI mpl.java:249) at > > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRespo > >ns e(HTTPConduit.java:2035) at > > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPC > >on duit.java:1940) at > > org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutput > >St 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$MessageSenderEndingIn > >te rceptor.handleMessage(MessageSenderInterceptor.java:62) at > > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorCh > >ai 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
