OPC UA .Net Stack Read service issues|OPC UA Implementation: Stacks, Tools, and Samples|Forum|OPC Foundation

Hi,

I'm using .Net stack to implement OPC UA client. Everything works fine, but I've found very strange issue. I was investigating it, but cannot find any clue even in the source code. Maybe there is some obvious mistake in usage of the stack or there is some way to warmup the connection?

My main issue is that when I’m calling a lot of Reads at the same time from .Net Thread Pool, I’m experiencing some problems at the beginning of the communication, the session is created, but first calls are very slow. It would be ok, but sometimes they are so slow, that the channel is timed out. After it is automatically recreated by the stack, everything works perfectly from now on. Very interesting thing is that when I increase the minimum number of working threads in Thread Pool it behaves much better (e.g. ThreadPool.SetMinThreads(16, completion)).

I haven’t experienced such issues when I execute exactly the same code from the same amount of concurrent jobs, but from within Threads that were created manually.

I've prepared sample application to reproduce this issue outside of my app. It is available here: source code and logs (https://onedrive.live.com/redi.....=file%2c7z). There is only a project, but it could be used as part of the UA Sample Applications.sln solution of the opc-ua-1.02-.net-stackandsamples-336.0-20150707 release. To run this, please update the UA configuration in OPC.UA.config.xml file and the address of the endpoint of the Sample Server at the beginning.

Later on there are a few variations over how the Read calls are made.
• DoJobsInNewThreads – specified number of threads are created and read is executed for n times
• DoJobsInThreadPool - specified number of work items in Thread Pool are created and read is executed for n times

In my environment (Windows 7, i7 processor) DoJobsInNewThreads(10, 1000, ...); is working correctly, while DoJobsInThreadPool(10, 1000, ...); is not. I expect that with a big load it will work slower, but stable. The strangest thing is that it would start to work (sometimes after reconnection) and it works from the beginning if the code is run from the Thread.

Best regards,

Grzegorz Ziemianski