Reusing a NioWorkerPool across multiple server and

问题:

Can I create 1 instance of a Netty NioWorkerPool and share it across multiple ServerBootstrap and ClientBootstrap instances? My application has so many idle threads and, at the moment, each Bootstrap is creating its own NioWorkerPool to use with 2*the number of cores on my machine.

If I do share this pool, what are the consequences? Will everyone equally get a chance to run eventually, or will either the server or client connections try and hog everything?

Even having one NioWorkerPool for servers and one for clients would be better than what I have.

As far as I can tell, this is not a repeat question. I have seen others talk about sharing the Executor, which I already do, I am more interested in sharing the actual NioWorkerPool instance. I have a thread dump of my processes and I have around 3000 threads, most of which are waitng for a Netty NIO event.

回答1:

Yes, you can. Here's an example:

ExecutorService executor = Executors.newCachedThreadPool();
NioClientBossPool clientBossPool = new NioClientBossPool(executor, clientBossCount);
NioServerBossPool serverBossPool = new NioServerBossPool(executor, serverBossCount);
NioWorkerPool workerPool = new NioWorkerPool(executor, workerCount);

ChannelFactory cscf = new NioClientSocketChannelFactory(clientBossPool, workerPool);
ChannelFactory sscf = new NioServerSocketChannelFactory(serverBossPool, workerPool);
...

ClientBootstrap cb = new ClientBootstrap(cscf);
ServerBootstrap sb = new ServerBootstrap(sscf);

Please note that you should not create a new ChannelFactory for each bootstrap instance you create. You should reuse the factory.

Sharing a worker pool between different connections means that a client socket and a socket accepted by a server socket can be handled by the same I/O thread which belongs to the worker pool. This is usually a good idea assuming that the handlers of those channels do not spend too much time when they are called by the I/O thread.

However, if the handlers of a certain type of channel spend a lot more time than the handlers of other channels, you might observe delayed responses from the channels who didn't got their turn soon enough. This issue can be fixed by making sure all handlers do not block and do its job as fast as possible and return quickly.