Excessive Threads in milo-shared-thread-pool-* During Deep Parallel Browsing - Is There Any Way to Control?

[ravi-kothapally]

Hi
I am running 50 parallel threads in my application, where each thread is performing a recursive browse of the OPC UA address space up to 50 levels deep.

During execution, I observed that a large number of additional threads (over 530 in total) are being created, and most of them are from the milo-shared-thread-pool-* thread group.

Is there a way to control or limit the number of threads created internally by the Milo SDK during such deep and parallel browsing operations?

Can this be controlled via any SDK configuration parameters or JVM options?

If not configurable, what would be the recommended way to control thread usage in such a scenario?

Thanks in advance!

[kevinherron]

Can you get a thread dump that includes this large number of threads?

My guess would be your 50 recursive browses are doing more concurrency work than you think. The client only uses the executor to deliver short running callbacks. You can replace the ExecutorService used by the client by setting one with a limited size thread pool on the OpcTcpClientTransportConfig, but I suspect that is not a good idea and could lead to "live locks" or other weird bugs.