Hello.


Information:

I1. There was no change to the XML-DA demo server during the period it was not accessible.

I2. There is no "artifical" limit on how many EasyDAClient objects you can create. But creating more and more EasyDAClient objects without having a way to properly dispose of existing ones (which is impossible if calls to them is hung) is not a solution. Each EasyDAClient consumes resources (memory, threads, possibly other), so at some point it is guaranteed to fail. You have not given details of the "crash", so it's not possible to tell exactly what has happened, but it is not really important anyway. In addition, the EasyDAClient objects share a common execution engine underneath, and if calls in preceding EasyDAClient-s are hung, the calls on new EasyDAClient objects will hang as well. This is not the way to go.


Questions:

Q1. Please confirm that so far, you were not able to reproduce the hang in ReadMultipleItems with our recent sample (the one that does *repeated* reads) when connecting to our demo XML-DA server. This is just to make sure we understand it right.

Q2. Does the hang within ReadMultipleItems occur in your normal production even when there are not apparent problems with the network or the server, OR is it always related to network or server problems (either real or simulated ones)?

Q3. Which operating system are you using (on the client side)?

Q4. Please clarify what you mean by "I have moved all my ... threads are into asynchronous execution, so threads are running always irrespective ReadMultipleItems function is hung or not by creating and terminating threads.". Which functions do you use to create the threads, and how do you terminate them?


Actions:

A1. If possible, please send us your source code. If you do not want to expose it on the forums, it can be done via email, to support09 (at) opclabs.com .

A2. Because you have written that it was possible to reproduce the issue with our sample code earlier, and the server has not changed, please continue trying, because it should be still possible. Capture the call stacks then. (this should be with the recent sample, the one that does *repeated* reads).

A3. Can you please modify our sample code (again, the one that does *repeated* reads) so that it connects to your XML-DA server (and uses some items in your server), and attempt to reproduce the issue? If it hangs in ReadMultipleItems, capture the call stacks in that state.


Thank you

It is OK now.

Unfortunately the call stack provided has not allowed the developer to figure out the reason.

He therefore continued to attempt to reproduce the issue on our side, but still was not successful with that. He was using a modified C++ application which calls ReadsMultipleItems, but does so repeatedly, with some delay in between, and was simulating networking and other problems during the test.

There is a suspicion that the issue may be related to something else that happens elsewhere in your application.

We would therefore like to ask you whether you can try to reproduce the issue (the indefinite "block" in ReadMultipleItems) on your side, with the code attached to this post (instead of your own app code) - either unmodified, or just targeted to your server and items, but otherwise the same (and, if the problem appears with his code, capture the call stacks again).







Also, can you please indicate (roughly) how long have you waited before you claim the ReadMultipleItems be "hung"? Was it e.g. 10 seconds, 1 minute, 10 minutes ? This is quite important. Please use at least 2 minutes in this test.

Thank you, and best regards

With some simplification, inside one process, and assuming that you do not explicitly set the .Isolated property on EasyDAClient to 'true', QuickOPC will use at maximum one connection to any given server URL.

When we close the OPC connection, the system can probably actually keep the TCP connection open for some time. This is a system behavior over which we have little or no influence, and which would affect any OPC XML client, no matter how written. But the "closed" connection will only remain open for some time, so even if this delay caused multiple connections temporarily, the extra ones will be closed anyway a bit later. An OPC server must generally be written to accept multiple connections anyway.

Note: The issue with a control not returning from ReadMultipleItems is still "at works" with the developer. I will let you know when I have more info.