2011/8/9 Freeman Fang <[email protected]> > Hi, > > As you're using Servicemix 3.3.2, for better performance of concurrent > client, you need add synchronous="false" to cxf bc consumer configuration. > Also you need configure a big thread pool for the cxf bc and cxf se > component, take a look at [1] to get more details. >
Hi Freeman, thanks for your reply. The synchronous attribute helped a lot but did not solved the problem completely. Now I can run the application with 100 client threads and it does not freeze using 16 as corePoolThreadSize, 256 as maximumPoolSize and 1024 as queueSize (global settings). But if I set the corePoolSize to 4, maximum to 256 and queueSize to 256 then the application freezes almost immediately. From the jconsole I can see that no new threads are created beyond the initial four. Considering the rules from the thread-pools page I suppose the queue is not full so no new threads are created. But all the cxf-se threads are stopped here java.lang.Object.wait(Native Method) org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.waitForExchange(DeliveryChannelImpl.java:721) org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.sendSync(DeliveryChannelImpl.java:482) [...] org.apache.servicemix.cxfse.CxfSeEndpoint.process(CxfSeEndpoint.java:452) and everything cxf-se related stops. Looks like there is a minimum number of threads required for a process to complete. For example 8 is enough, but 4 is not (my case). Is this correct? Considering that the number of threads does not increase how can I be sure that I have enough for a specific complex BPEL process? Should I set the queue lenght very low to force new threads to be created immediately (I tryed, this works but looks like a bad hack)? Should I set the corePoolSize very high and do a lot of testing? For my specific application this is a big issue. I found almost nothing about it with google. Am I doing something wrong? For example calling sendSync is bad practice? Should I avoid it at all costs? Thanks, bye Lorenzo
