Re: netty thread pool clarification

2013-06-25 Thread Hack Kampbjørn
You had 160 tps with a 100ms sleep that gives a pool of 16 threads. In Netty 
4.0 the default pool size will be twice the number of cores, I guess it's the 
same for current 3.x that camel is using. You are running on a system with 8 
CPU cores (and 0% overhead inside netty or camel).

A computer cannot run more task that number of cores. If your code is not 
blocking (camel-netty doesn't block but your thread.sleep example does) then 
any thread pool bigger than number of cores is big enough.

Why are you using Thread.sleep? Are you trying to simulate a CPU heavy task, 
then you should add more CPU cores. If you are simulating an external system 
that will take 100ms to respond then convert your SleepProcessor to use 
AsyncProcessor and schedule the callback object to be notified after 100ms

http://camel.apache.org/asynchronous-processing.html


On 2013-06-25, at 13:56, kiranreddykasa  wrote:

> Hi,
> 
> Thanks for quick reply.
> 
> And generally on a netty consumer is it okay to use additional thread pool
> or default thread pool is enough ?
> If default pool is enough what is it's pool size and how can I increase it?
> 
> 
> 
> -
> Regards
> 
> kiran Reddy
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/netty-thread-pool-clarification-tp5734734p5734738.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



Re: Camel JAXB DataFormat is not thread safe

2013-08-22 Thread Hack Kampbjørn
A workaround is to use a SchemaFactory implementation that is thread safe. The 
one bundled in JDK is not but the one in Xerces is.

On 2013-08-22, at 12:38, solimo  wrote:

> Oh, how could I miss CAMEL-6630. Thanks.
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Camel-JAXB-DataFormat-is-not-thread-safe-tp5737748p5737759.html
> Sent from the Camel - Users mailing list archive at Nabble.com.