Hmm, the posts are numbered on the right side to their titles, but links to them doe't seem to work well. I meant your post dated 07 May 2015 10:29.

Given the type of issues and requirements you have, I still suggest to set Isolated to true.

Best regards

Let's keep this thread for now; but in future, whenever it is clear that there are separate issues (and I understand that sometimes it is not known upfront), it is much better to maintain separate forum threads.

I think I know understand much of what is happening. I have not known (or, I might have overlooked? somewhere in your posts), that you are accessing EasyUAClient from multiple threads.

If this happens, it is by design that we serialize the calls (it is not precisely queuing, but it may appear as such). The serialization is by design, and it is done *per client session*. That is, if you have one session open to your target server (more about it later), calling an operation from one thread blocks until operations being performed on that one session from other threads complete (this applies to ReadXXXX, WriteXXX, BrowseXXXX and similar, it does not directly apply to SubscribeXXXX/UnsubscribeXXXX). If, however, you used sessions that work with two different servers, or two sessions that target the same server, this serialization does not happen.

This explains many of the issues you reported (not sure about them all, especially you very preceding post, but it is a start).

If you want to truly perform multiple operation on the same target server at once, (and if the server supports it - I do not known that - it may serialize on its side as well), then here is what you should do: Create one EasyUAClient instance for each activity that needs to be kept in parallel (this may be, in your case, one in each of your threads). Right after 'new'-ing it, set its Isolated property to 'true'. This will case it to use a separate session for its operations. This of course requires some more resources, but it should not be a problem.

Can you please do this, and then let me know if there are still problems outstanding?

Some more information:

A. Unless there is a specific reason that I do not know, why don't you replace the periodic reading threads (e.g. 1 and 2 in your forum post #3094) simply by OPC subscriptions as well? Besides other advantages, it won't create that much blocking.

B. While the "one operation at a time per client session" behavior described above is by design, the OPC UA subscriptions should - ideally - run unaffected by that. BUT, I have now quickly looked into the implementation of the OPC UA .NET Stack (which we use on the lower level, and it is a code from OPC Foundation), and, to my bug surprise, I have found that this may not be the case. If so, we will probably have to put some workaround into QuickOPC, but clearly the developer won't expect that Reads, Writes etc. should be able to "damage" the ongoing subscriptions. Using a separate EasyUAClient with Isolated = true would currently be a workaround here as well.

Alright, you are changing subject here; please start a new thread in such cases.

The original problem does not need Wireshark to troubleshoot at all; the 3 minute time period is between source value change and the server sending it out, thus there is hardly anything to look at with Wireshark.

To the slow "write" issue: Unfortunately I do not see enough of a Wireshark data to be able to tell more. It would have been helpful if you could send that. One possibility is that what takes the long is an additional read that we may have to do before the Write when the data type is not specified. Can you please post a couple of lines of your code that call the Write?

Thank you

With the problem at hand, there is absolutely no need to tweak the keep-alive mechanism. It works fast enough. The connection *is* alive. It is just that the server does not think it should send the data at the moment you intended.

The cache reads *are* the default.

By specifying a different maximum age with the read, depending on your application needs, you can choose a read from the device (zero), or something in between - the server should then make a decision where to take the value from.

Best regards