Thread waiting for resources, not released

[1439695608]

When the device is disconnected, these threads will be continuously created and will not be released until the threads cannot be created

[1439695608]

Does the author know how to solve this problem, which will gradually deplete the thread pool

[kevinherron]

@1439695608 sorry I'm not sure what issue you're trying to describe, and I'm confused because threads are from a thread pool belonging to Milo?

Can you perhaps provide a full thread dump using something like jstack?

[1439695608]

tcs3.txt
this is a thread dump file.I connected 7 devices using Modbus and found that when the Modbus server network is disconnected, many threads named "Modbus net event loop -" and "milo net event loop -" are created until the number reaches 40 and stops. Even if I call the disconnect method, these threads will not be destroyed. Unless Modbus. leaseSharedResours() is used, but the Modbus. leaseSharedResours() method can affect other device connections.

[1439695608]

tcs3.txt

[1439695608]

My native language is Chinese, so there may be some unclear expressions. Thank you for your answer. This problem has been bothering me for a long time. I have tried to search for the reason in the source code, but currently I only see that in the connect() method, a thread was created using the Executors. newSingleThreadScherderdExecuter() method but it did not close.

[kevinherron]

You can provide your own EventLoop and Executor when configuring clients:

modbus/modbus-tcp/src/main/java/com/digitalpetri/modbus/tcp/client/NettyClientTransportConfig.java

Lines 33 to 34 in 156100d

	EventLoopGroup eventLoopGroup,
	ExecutorService executor,

These are needed by the library and if you don't provide them at configuration time then default instances are created. They will live until Modbus.releaseSharedResources and Netty.releaseSharedResources are called, which indeed can only be called when you are entirely done using the library and your application is shutting down.

The default NettyEventLoopGroup uses something like 2 * numberOfCpus for its thread pool size, which is why you see so many threads.

[1439695608]

Thank you very much for your answer, which has brought me one step closer to solving the problem. I will modify and continuously observe the operation of my equipment for a period of time.