Hi,

Some extra notes from me:

How many UaClients we would be talking? 10s, 100s?, 1000s??

The ‘stack layer’ due to historical reasons do utilize (sometimes very much) shared threadpools in the StackUtils class. The ‘NonBlockingWorkExecutor’ gets equal threads to CPU cores and the ‘BlockingWorkExecutor’ will get 64 threads (configurable via StackUtils.setBlockingWorkerThreadPoolCoreSize(…), this must be called before other interactions with the SDK, start of main etc.).

Also each UaClient does use 2 internal threads (one reads the socket in the ‘stack layer’ and another in the ‘SDK layer’ doing status checks and PublishRequests/Responses).

Also it should be noted that nowadays UaClient does by default Read/Browse the Types part of the server on connect.

Message decoding happens on the blocking work pool (so socket reading can continue), thus it should be noted that while the clients obiviously do not interact with each others per se, they “indirectly do so” by sharing the same “decoding pipe” due to the pool. In practice I would say this is something that you can probably ignore, but is something to we aware; might help later if there are issues (and hopefully increasing the pool size would help then), but let us know if there are any.