How long does it take, in these clients that work, if you subscribe to 1000 items, before you get a response? In seconds. I am assuming that the error log you sent me was with a similar configuration (i.e. they you have also attempted to subscribe to ~1000 items, at once).

What I am trying to determine is whether the problem is simply not in the detection of server irresponsiveness on our side. If it takes long in other clients as well, but they simply ignore the fact that the server is irresponsive in the meantime, we should be able to resolve it by turning off the corresponding checks on our side.

Regards'

It is quite possible that the server gets bogged down by a request to subscribe to many monitored items at once, and it fails to keep the connection alive. It is "understandable", but still it is a server problem that should be fixed on the server.

If you subscribe to 1000 tags using the Kepware UA client, how fast is it before it first responds? I am trying to determine whether they do it one by one, or at once. Is it as slow as in your "one by one" test, or is it significantly faster?

Regards

Thank you very much. Regarding the discussion about Isolated: All that I wanted to make sure is that you do not unnecessarily create too many objects that use Isolated = true and are used to connect to the same target endpoint - in which case each of them would use its own connection, which of course increases the load on the network. If you know what you are doing i this respect, then it is OK.

I am very grateful for this last error log. It is simplified (just one connection) and shows the issue clearly. It looks like there is simply no response from the server for extended periods of time (over 33 seconds). That causes the client to raise the error. There are mechanisms built into the OPC UA that require both the client and the server to respond during certain time, to make sure the connection is still alive. It is worth noting that not all clients actually check that.

Note: I cannot tell form the logs whether you are creating your own subscriptions. The errors I am seeing are most likely related to an internal subscription that we make to monitor the server status. It might be possible to mitigate them by turning this monitoring off, by setting SessionParameters.StatusSubscriptionSamplingInterval to -1. But such problems usually affect all subscriptions, so the chance that this would help is not big. But it is worth trying.

I suggest that you try the above setting. If that does not help, take the error log again, and do it in parallel with taking Wireshark log (kb.opclabs.com/Collecting_information_for_troubleshooting). The resulting info should clearly point to a fault on either client side or server side.

One more suggestion: Please enhance your error output by logging the time (up to milliseconds if possible) of each log entry.

Best regards

Regarding the error log, before we start deeper troubleshooting: It appears that there are at least 3 connections being made and maintained to the server in parallel. That's certainly not good if you wanted to reduce the bandwidth. Are you creating multiply EasyUAClient objects with Isolated == true? If so, do not do that in this case...

Best regards

In COM (Delphi):

- The EasyUAClient object has InstanceParameters; they always apply and you can set them as you need.

- The EasyUAClient object has IsolatedParameters; they are taken into account when EasyUAClient.Isolated == true (in which case there will be a dedicated connection to the target server for that particular EasyUAClient instance).

- When EasyUAClient.Isolated == false (the default), the EasyUAClient.IsolatedParameters on that instance are ignored. Instead, all such objects use a shared set of such parameters, which in .NET you can access through a static property EasyUAClient.AdaptableParameters; in COM there are no static members, so you do that by instantiating an EasyUAClientConfiguration object, and there is an AdaptableParameters property on it.

- And last, there is a set of parameters that are *always* shared, and they are in .NET in a static property EasyUAClient.SharedParameters, and in COM you can access them by instantiating an EasyUAClientConfiguration object too, and there is a SharedParameters property on it.

Best regards