Lorenzo,
Generally speaking, if you can avoid the use of sendSync, it becomes a lot easier for the application to scale and to be tuned. If your application requires you to use sendSync, every call to sendSync will block the thread until the exchange has been handled, forcing you to ensure that the configuration has enough threads available to handle the workload. This becomes especially important if you are use routes with multiple endpoints from the same component type, as those will all need threads from the same thread pool if you don't add endpoint specific thread configurations. I would set the core pool size as low as possible, but keeping in mind the minimum number of threads that you need to actually handle the exchanges (e.g. 8 sounds like a good number in your scenario). To allow for the system to scale under load, you can then increase the max pool size and lower the queue size for those particular endpoints that need it. Those threads will only get created on demand and will also be removed after a timeout period to ensure the system thread count goes down again after a period of high traffic. Regards, Gert Vanthienen ------------------------ FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Tue, Aug 9, 2011 at 1:51 PM, Lorenzo Bolzani <[email protected]> wrote: > 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 >
