Hello,
I received the code. Thank you.

I do not see any problem with your code as such, but I have realized something that could be related:

It might be dangerous to call operations on EasyUAClient from inside an event handler or callback. It seems that we somehow forgot to warn our users about it in our documentation. In a future version, we will either make sure it is safe, or make it clear in the documentation. A can foresee a possible deadlock, which would explain the inability to recover. I cannot be sure if we are dealing with it, but is my nexct recommendation, to remove such calls.

I suggest that you store the incoming events into a queue, and then process the queue from a different thread. I understand there is work associated with that, but at the moment it seems to be as the thing to do.

I have also figured out why some initial LogEntry data is missing. This is just a minir issue, but it is unfortunate because it has prevented me from checking the QuickOPC version and some other parameters of your system. What happens there is that the EasyUAClient.LogEntry is a static event, and is being raised already when the first "new EasyUAClient" is called. In your code, however, you have "new EasyUAClient" as part of the field initialization, while the adding of the event handler for LogEntry comes afterwards. If you can, replace the initialization of the field by assigning "new EasyUAClient" to the member fields *after* you add an event handler to the LogEntry static event.

And, more or less out of desperation, we may consider obtain a lower-level trace (the messages from the OPC UA stack) - but preferrably only after the above change is made (with event queuing) is made. Please see the attached document with details about that.




Thank you

I apologize, the email address should have been support09 (at) opclabs.com .

Thank you for the log files. Do I assume correctly that the current issue we are discussing occurs at 6/15/2016 1:17:58 AM ?

No, I do not think we need to look hours back for the cause - it is unlikely.

Regarding the reasons to disconnect like this, in fact reasons like those you have listed shouldn't be causing it. It is surprising me as well. The legit reasons are:

- when you unsubscribe from all monitored items, or
- the EasyUAClient is disposed of or finalized.

It is also somewhat surprising that apparently, the component *does* attempt to reconnect after 1 minute (6/15/2016 1:18:59 AM), but that fails with a timeout. However I think we should focus on finding an explanation for the thing that happens first, and not on this.

Are you putting all LogEntry data into the logs you have sent? I am surprised not to see some that I would expect. For example, assuming that you do a service restart (and that creates a new process) around 6/15/2016 1:26:48 AM, I would expect to see many more messages from the LogEntry event, showing parameters of the system etc. Or, it wasn't a restart like that after all?

Regards

More to this:

Can you please send my way the relevant pieces of code you have? I am mainly interested in

1) The part(s) that instantiates the EasyUAClient object, subscribes, and unsubscribes.
2) The event handler.

If this cannot be done, for confidentiality reasons, over the forums, use email to support (at) opclabs.com.

Thank you

The information contained in the LogEntry events is only meant to provide an additional insight into problems. However, with subscriptions, the delivery channel for errors is the subscription (event handler) itself. That is, if there is a problem, we raise a MonitoredItemChanged event, in which the EventArgs contain a non-null object in the Exception property, and it is *there* where the problem is primarily described.

I have it for almost guaranteed that you must be receiving such event notifications, approximately at the same time as the LogEntry events. I need to know the information contained in that Exception property (and, if it has an InnerException, then this inner exception as well - and so forth).

Thank you

Are you saying that you get these disconnection message while your code is subscribed to some monitored items? Because, if you were not subscribed to anything (or have unsubscribed from all items), *or* if you were doing just one-time operations like Read-s and Write-s, there would be nothing wrong with a disconnection like this.

That is still the same message, therefore my previous answer applies. Please observe the behavior with build 5.35.1173.1.