Hello.

I was able to reproduce the issue, and fix it. In fact, it *was* the issue I suspected, the one fixed in 5.54.1151.1. However, due to a mistake in the build procedure, the fix remained in .NET Framework code and was not automatically merged into .NET Core part. This explains why 5.54.1151.1 resolved the customers' issue (they were using .NET Framework), but you were getting the very same problem even with later builds - that's because you are using .NET Core.

Please download and rebuild with 5.54.1296.1. This is now on our Web site and on NuGet.

Thank you for reporting the issue and providing valuable information.

Best regards

Very good. Thank you. I will continue as planned, but this information brings me much closer.
I will let you know here when I have an update.

Thank you very much. This sounds very good. Here is what I plan to do:

1. Try to reproduce the issue without your tools first. The reason why I haven't done that yet is because (a) I was assembling the necessary information, and also (b) because we have done similar tests and they appeared to work. It needs to be seen whether e.g. NET Core plays a role (most of our testing is done under .NET Framework).

2. If I fail to achieve a repro myself, I will ask you for your tools and we will figure out a way how to deliver them.

Best regards

One more question please:

Somehow I was under impression that it is known that you are running under .NET Core, but I cannot find an evidence for it in this forum thread. So, are you running your app under .NET Framework, or .NET Core? If it is .NET Core, is it on Windows or Linux?

Thank you

The reason I was concerned about the build numbers is as follows: We had an issue with similar symptoms: Things were working OK but notifications stopped if there were no data changes. The bug affected, however, only the notifications being sent from QuickOPC to users code. Everything worked fine in between QuickOPC and the server. We fixed the bug in build 5.54.1151.1. The customers that had the issue then reported the fix had resolved the problem.

So, it is really critical to use the newer builds. But according to your report, you have them already.

The similarity with this issue is however something that bothers me. It probably is *not* the same thing, because there are important dissimilarities as well (e.g. the fact that it behaves differently in the debugger). In order to test this, can you please set the QueueCallbacks property on your EasyUAClient object(s) to 'false', and re-test? Plan: if it helps, we are dealing with a variant of the old issue. If it does not help, it is something truly different.

--

The fact that there are event entries about publishing stopped/recovered is suspicious, although by itself it should not cause the particular issue (it is a warning; when it escalates to a problem, your code should be notified - so from my point of view, the first issue here would be the absence of the notification, and not the actual "publishing halted" issue). Is any part of the system under heavy load (the server, the network, the client side - CPU etc.?)

--

You described that/how you were able to reproduce the issue in a constrained environment. When you do the same repeatedly, does it *always* happen, or just sometimes?

--

Can you please elaborate on what you mean by "sharing our simulator with you", and the test app? Are you saying you have two pieces of software that we can run here and try to reproduce the issue?

Best regards

Thank you. Both these builds (5.54.1156.1 and 5.54.1281.1) should be OK. I just wanted to be sure that you were not running something older (in which case there would be an explanation for the issue).