Camel-netty component did not implement oio model of netty, we can only use nio one, however it uses default workerCount parameter from Netty, which is cpu_core_threads*2.
This is far from enough when the underlying app is a little bit slow, e.g. a traditional transactional application. In this situation NioWorker threads become an obvious bottle neck.
I think that exposing workerCount is a very practical yet effective way for one to broaden the usage scenario of camel-netty in various network communication/application environment.
I add a workerCount parameter in the configuration, one can use it in the Endpoint URL: "netty:tcp://0.0.0.0:1111?...&workerCount=256&...". I leave the default value to 0 so that one can use Netty default policy by omit the param.
I have tested the patch in a 2 core(4 Threads) machine, using 256 workers, it significantly improves the performance by 15 times, than the default parameter of only 8 workers, while CPU usage only increase 5 times.