I am glad to hear this.

The exceptions you mentioned (BadSessionClosed etc.) would be normal if they appear in relation to us closing the session. The process of shutting down the connection brings situations in which these exceptions cannot be prevented, and they are truly harmless in such case. As a general rule, we do now "swallow" any exceptions from lower levels, *unless* there is a specific and good reason for it (as above) and ignoring them is justified by good reasoning (and not just because we "do not precisely know what to do about them").

If, however, their occurrence seem to be related to the "publishing stopped" or other misbehavior (does it? - please clarify), then of course that would be suspicious.

If your debugging involves breakpoints, or some other considerable "pausing" or significant slowing down of the app, then I would not be surprised about the "publishing stopped" occurrence. Otherwise, just having the debugger attached and doing some tracing or so, should not have such negative effect.

Best regards

Regarding the Keep Alive setting: Actually, there are two Keep-Alive mechanism, and I hope I have not confused them in one of my earlier replies to you.

The first keep-alive on the Session (=higher) level, and consists of client-invoked Reads of certain server nodes. This is the one that is influenced by our KeepAliveInterval or KeepAliveIntervalDebug in our "session parameters". If the Reads do not return for a delay that is greater than 2 of these intervals, an error is triggered - however, that is not the "publishing stopped" error we are dealing with; it would rather indicate the actual communication error, or BadNoCommunication, "Server not responding to keep alive requests."

The second keep-alive mechanism is on the Subscription (=lower) level, and it is this one that can trigger the "publishing stopped" error. With some simplification, it is raised when the client sees no notification from the server for the specific subscription for a keep alive interval, which is computed as the publishing interval of the subscription times the keep-alive count. Both these are given to the server by the client, but can be revised on the server side. Currently we pass in the default keep-alive count of 10 to the server, and this cannot be changed from your code. And, observing the Wireshark logs, the Kepware server does not revise this number. This means that e.g. for a subscription with publishing interval of 500 milliseconds, the "publishing stopped" error would be raised when the client does not see any notification for that subscription from the server for 5 seconds.

In general, in your situation, which truly does not involve a high load on the system or extremely fast communication or such things, I do not see why it should be necessary to start tweaking these parameters in order to achieve a reliable communication. The problem is probably elsewhere.

I will reply with the conditions that lead to "publishing stopped" separately.

Version 5.31 is no longer updated with bug fixes. Version 5.32 is.

To you previous post - couldn't it be that in case of failure test cases, you just somehow dispose of the EasyUAClient, but without calling UnsubscribeAllMonitoredItems? This, in combination with the problem on our side (UnsubscribeAllMonitoredItems not called automatically upon Dispose), could cause the connections not be closed. But, with the RobotClient class, as longs as its Dispose is called, this should not happen...

I see. In this scenario, I agree that it is reasonable to isolate the two usages of the EasyUAClient - as long as the number of such instances is limited to two, so that new ones don't get created without old ones being removed first.

I have two questions:

1. You wrote "In the testing environment the application client and the robot simulator run under the same process." OK but how does that work with the MS test tool? Is it in form of unit tests? - in which case you won't be able to have the real (WPF) app inside the test - so you have just part of it there, the classes that you need to test? Or is it in the form of "Coded UI" test? Or something else? I am asking these questions because they are relevant to the lifetime of the objects, which seems to be the first problem we need to deal with.

2. You wrote "A typical test case will run for about 30 - 45 seconds with continuous communication..." In the Wireshark capture, most cases I see show some Subscribe, then Reads/Writes, and Unsubscribe - but quite sooner, typically just after 3-5 seconds, not 30-45. There would be nothing wrong with it if you wanted it that (short) way, but is that really the case? I mean, is your statement about 30-45 seconds imprecise (in which case everything would be OK), or do you believe that it is correct - in which case I would have to investigate WHY I see "Unsubscribes" much sooner than that.

Not sure about the true "publishing stopped" cause, but there is at least one clear problem seen from the capture (and pointed out by Kepware), and it is that the OPC UA sessions are not being closed as you/I would expect. I have tried various combinations in code on my side, but could not reproduce the problem so far. For this reason, I would really appreciate if you can put together a "self-contained" project that shows the problem.

The "publishing stopped" might then be just a consequence of having too many open sessions; definitely we need to resolve the session closing first.

I have discovered one problem that we need to fix, however that should not be the cause in your case: Just doing Dispose (or running the finalizer) on EasyUAClient does *not* automatically unsubscribe all monitored items. You always have to do it from the code, using UnsubscribeXXXX methods. We will fix this. Your code, however, appears to be calling UnsubscribeAllMonitoredItems, and therefore you should be OK in this respect now. Just please pay attention to it in case you write another code that uses EasyUAClient, besides the code in the RobotClient class.

Best regards

Thank you. I am starting to understand but still have some questions.

1. Is the RobotClient class used both by your app (= the real client) and the test tool?

2. Is the test app the WPF/MVVM part, and the test client is run just using the Microsoft tools, i.e. it is not an application as such?

3. (this may come from the answer above): Is the real app running in process different from the test tool?

4. The application log file I have received is from the real app, or from test tool? Which one is having problems - or both?

5. I understand that you are disposing/closing the client in the real app. What about the test tool - how are the individual tests being finalized there?

Best regards