Professional OPC
Development Tools


Online Forums

Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.

Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.

Do not use the Contact page for technical issues.

Using KEPServerEx Sim Driver && Getting dropped subscriptions

04 Mar 2015 22:10 #2907 by Bmello4688
I think the error is related to publishing stop exception because one of the logs I received said Session.RemoveSubscription because of BadSessionIdInvalid.

Other than on a close/dispose of the session why would I receive a BadSessionIdInvalid?

Please Log in or Create an account to join the conversation.

04 Mar 2015 19:54 - 04 Mar 2015 19:55 #2906 by support
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
Last edit: 04 Mar 2015 19:55 by support.

Please Log in or Create an account to join the conversation.

04 Mar 2015 19:40 #2905 by Bmello4688
Finally progress.

I have made some progress. By adding some logs on creation and dispose I found out that some higher level objects were never calling dispose therefore the easyUAClient was never being disposed. I also upgraded to the latest version which has tripled the speed of my tests.

Now I am seeing only 1 instance of subscription drops for a test. In this case I am seeing tons of ServiceResultExcetions in my intellitrace logs. The exceptions are BadSessionClosed, BadSessionIDInvalid, and some other ones.

Does this actually mean anything or is the easyUAClient just eating the exceptions underneath the covers.

Also another thing I am noticing is that the dropped subscriptions occur more when I am debugging. Is this just because of the limitations of KeepAlive or is there something I can actually do about it?

Please Log in or Create an account to join the conversation.

03 Mar 2015 13:45 - 04 Mar 2015 20:01 #2878 by support
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.
Last edit: 04 Mar 2015 20:01 by support.

Please Log in or Create an account to join the conversation.

03 Mar 2015 13:01 #2877 by support
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...

Please Log in or Create an account to join the conversation.

02 Mar 2015 21:42 #2873 by Bmello4688
Just an update. We commented out the change to Keep Alive and now the dropping of subscriptions seems to be occurring less. I am having a really hard time reproducing the Exception. Now the Exception is more intermittent between running of all tests. Sometimes it happens sometimes it doesn't. Is there anyway you can look to determine when the easyUAClient throws the Exception of publishing stopped? It is really hard for me to reproduce when I do not know the use cases for why the exception would be thrown.

I have not taken the new version yet. Will you be updating the existing build with the bug fixes?

Please Log in or Create an account to join the conversation.

02 Mar 2015 20:38 #2872 by Bmello4688
Yes the application and simulator are run under a unit test. With MVVM, the application can be tested in a headless mode(No UI) where calling the UI or ViewModel interface is just like calling methods and properties on a class.

When the unit test finishes I dispose of the application and robot simulator.

I have 10 or so unit test cases. When I run all of them, the passing ones take about 30 -45 seconds while the ones that fail take a much shorter time ~3-5 seconds. What you could be seeing is the failure test cases. When a test fails and end the run I dispose of everything so what your seeing is probably my test cleanup code.

I'm still working on getting you a contained client.

Please Log in or Create an account to join the conversation.

02 Mar 2015 08:00 #2868 by support
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

Please Log in or Create an account to join the conversation.

27 Feb 2015 19:44 #2867 by Bmello4688
The robot client is used by both the application(the real client) and the test tool (aka robotSimulator).

The application is WPF/MVVM the robot simulator is just a test class that is used within an MSTest unit test method. We use microsoft toll vstest (visual studio 2013) to run our tests.

In the testing environment the application client and the robot simulator run under the same process.

The app log is logging from the application(real client)

I am disposing of both clients when I finish the test method. I am using a using wrapping so I know it will dispose even on an exception.

Please Log in or Create an account to join the conversation.

27 Feb 2015 18:52 #2865 by support
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

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.228 seconds