Thank you very much.
I have received the email with the data as well.
There is a plenty of new information, and a plenty to reply to – all comes below.

Comments and observations

1. According to the communication on this forum, I was expecting the code (which I partially have now), and the server configuration (which I do not have yet?). I did not know you were going to make the Wireshark capture right away and start resolving with Kepware. We could have changed the code first (“Things to do” further below).

2. Indeed the communication does not look how it should. But is too early to conclude where the problem originates. Under normal circumstances the things observed do not take place: only one connection is used, and when subscribed, it stays open. Therefore there must be something somewhere which causes the different behavior in your case. It could be the component (us), or your code, or (less likely) the server.

3. Not only there are sessions not being closed, but from the very beginning there see, to be two connections being made in parallel. We need to establish why. I think this is related to the Isolated setting – this is covered further below in the Questions.

4. The subscription with sampling interval 15000 ms and publishing interval 7500 ms is an internal subscription to monitor the state of the server. Kepware has not noticed that there is a second subscription being created right after that, which is the one that holds your monitored items and has their parameters.

5. It appears that the first “real” failure seen in Wireshark (ServiceFault, frame #5810, approx. 82.885 seconds from start) corresponds to the first “publishing stopped” in your app log (2015-02-23 22:23:25,317). The communication, however, is far from normal from the very beginning – this moment is just when the problems become apparent.

Questions

6. What kind of project is your application? E.g. console app, Windows Forms app, Windows Service, Web service, Web app, or something else?

7. Please describe the lifetime cycle of the RobotClient object. If possible, send a code that creates/calls/destroys them. Are you creating just one, or more – how many? When/for what purpose are they created? How long do they typically live? Are you explicitly calling Dispose() on them? Please explain this as thoroughly as possible, it is important.

Things to do

8. Do not set EasyUAClient.Isolated to ‘true’, unless you have a solid reason for it (if you this is the case, please explain and discuss it here before we go any further). With Isolated = true, if multiple RobotClient objects are instantiated, each one will end up with its separate connection to the server. Set Isolated back to ‘false’. Note that consequently, the parameters that you are currently setting under IsolatedParameters will need to be set in the static property EasyUAClient.AdaptableParameters instead, just once, at the beginning of the program.

9. You set RetrialDelay on a session and on a subscription to 200 milliseconds (and ServerShutdownRetrialDelay to 1000). These are extremely small values that are not going to help anything. In fact, they only make matters worse, because they complicate the diagnostics and troubleshooting, and can create unnecessary extra load on the system. Refrain from changing the defaults, or make them at least several seconds long.


Recommendations
These I think do not relate to the problem at hand, but are worth noting anyway.

10. Upgrade to version 5.32, free of charge (download from our Web site). Besides some bug fixes (but none to this particular problem, as far as I am aware), there are improvements in diagnostics (things being logged).

11. Do not use the handles returned from SubscribeXXXX to identify your subscribed items (in a dictionary). Please read the user manual (Concepts), section Best Practices – there is a whole chapter about it.

12. For efficiency, if you can, do call methods like SubscribeMonitoredItem, Read etc. sequentially. Prepare the arguments upfront and then call SubscribeMultipleMonitoredItems, ReadMultiple etc. More about it – in the Best Practices section again.

13. Your code combines the hooking of instance events (MonitoredItemChanged) in the same place with the static event (LogEntry). If more of your instances are created, this would mean that the event handler for LogEntry would be called multiple times, and it logs to the same storage, there will be duplicate entries.


Other notes

14. It seems that you can control which event types (from our LogEntry) go into your app log. The app log you have sent seem to only have the errors. If we get to do something like this again, please capture the warnings and infos as well.

15. It’s a pity that I do not have a self-contained code that I can run, reproduce the issue and work on it here. Do you think you would be able to modify the app so that it can be sent over in full? (it does not have to contain the app logic, it just has to be able to show the problem).

16. Alternatively, if you give me the data such as item names etc. . (or even without them, as a kind of template), I can put together an app that just subscribes, reads, etc. as it should, verify that it works here and behaves correctly on the communication level, and then send it over to you to see whether shows the problem on your side – and if it does not, we would look into how is your own app different from this baseline.

Best regards

Unless the information is confidential or extremely large, the best way would be to post it as an attachment right here (not all file extensions are permitted, ZIP it if you get into problems). See the Attachments/Add File controls right below the edit box where you are typing the new text.

If you cannot do this, please email to sales09 (at) opclabs.com.

Thank you

I see. Thank you.

Is there a way I can reproduce it on our side? Can you send me the KEPserver configuration, plus an indication of the KEPserver version your are using, and your code, or relevant pieces of it?

Best regards

Please always state whether you actually observed a problem in your program - i.e. in this case, whether you have received an error in the notification handler. Has it been the case, when changed the sampling rate to 1000 ms, or not?


Log entries alone are not necessarily a problem.

If you received the error in the notification handler, can you please then post the full event log?

Thank you, and best regards

As far as I can tell, you have been specifying a sampling interval of 50 milliseconds. It's got to be somewhere in your code. Yes please, change it to 1000 milliseconds and observe the result.

Subscription IDs are assigned by the server. About the only requirement on them is that they must be unique inside a (client-server) session. The fact that they continuously increase does not imply that they are not getting cleaned up; it is one of the reasonable ways to implement the server.

The sequence numbers, on the other hand, must start with 1 and increase by 1, that is dictated by the OPC UA spec (in fact it is much more complicated, as the actual order in which they are received may differ, and there are acknowledgements/republish mechanism etc.).

Best regards