Memo (phone calls):

- the Access denied issue is separate from the performance issue (prb writing 40000 items), now focusing on the Access denied
- Access denied appears remotely only, from desktop apps incl. our Demo app. Browsing for servers works OK, however other ops (incl. browsing for items) throw this.
- Softing demo client works fine from the same machine
- recommended best way to compose ServerDescriptor but that should not have been the issue
- recommended to try all combinations of our flags that influence the DCOM security (link to the other post on forums)

Z.

Hello,
Thank you for your reply.

I am still unsure about the setup, steps and symptoms, therefore I have put (at the bottom of the post) a new set of questions. I kindly ask you to respond to them as well. They are designed to get us further, but I will explain at least some general facts so that you can understand a bit better how are things supposed to work and what can go wrong.

A. Regarding your earlier, where you have asked about the limit on number of items:

There is no total limit in our software, but there are certain configurable parameters which may influence the practical achievable limits. First, as I have explained, the operations are performed by separate threads, and queues are used to pass the information. The queues have maximum capacities, which default to numbers that are sometimes lower than 40000. The capacity should be such that it can hold all items being processed at one time. You should therefore increase the capacity, using e.g. a code similar to this (performed at the beginning of you program, even before you start making OPC calls):

EasyDAClient.SharedParameters.Client.RequestQueueSize = 100000;
EasyDAClient.SharedParameters.Client.ResponseQueueSize = 100000;
EasyDAClient.SharedParameters.LinkCallbackQueueSize = 100000;
EasyDAClient.SharedParameters.Engine.TopicLruSize = 100000;


In addition to possible queue overflow problems, the operation can simply take quite long, and because we have a timeout on the operations, it may time out. The timeout error message would be something like "Write not completed…". (Note that "Access denied" actually indicates a very different problem, but I want to explain this anyway, because I am not sure if you are dealing with just one issue or more). The total time taken is a combination of processing on the client, processing on the server, and the network transmissions. All in all, I am not surprised by times such as 16 seconds for 505 items, especially in a remote scenario. From our experience, it would be mostly the server processing and the network times that are responsible for that, and not the client part. If contested, one can use tools such as OPC Analyzer to get better measurement on which portion of the time has to do with the client, and which with the network + server.

What this also means is that for 40000 items, the time needed is certainly longer than 1 minute: But we have 1 minute as a default timeout. In order to make this, the operation needs to be split into smaller calls, or a longer timeout needs to be configured - e.g, like this (this sets it to 30 minutes instead):

easyDAClient1.InstanceParameters.Timeouts.WriteItem = 30 * 60 * 1000;


And one more thing: By default, QuickOPC uses asynchronous (reads and) writes. That is better for several reasons, but has a disadvantage of higher complexity and a need for additional processing of the callbacks. You can try to switch to sync operations like this:

easyDAClient1.InstanceParameters.Mode.AllowAsynchronousMethod = false;



B. "Access denied" error. In vast majority of cases, this has to do with COM/DCOM configuration and security settings, and affects the connection to the server as a whole. In very small percentage, it can be related to a security on the item (tag) itself. But I have hard time believing it has anything to do with the number of items you are dealing with (a question to it is further below) In all cases, it is not an error directly produced by us (QuickOPC) - it is something that came from the system or the server when attempting to perform the operation and everything around it.

When it is COM/DCOM security issue, the Source property in the exception object you receive will be likely empty (because we could not reach the server). If we could connect to the server, and it was the server itself that rejected the operation for security reasons, the Source property will contain the ProgID or CLSID of the server.

If it is a COM/DCOM thing, then there are many settings in the system, and also some on the server and client side, that have influence, and I recommend you look at various materials on the Web that cover it: The topic is huge. I can only give specific instructions to the parts that have to do with our client. There, the first thing to watch out for is the identity of the process that is the client. The various useful test client practically always run as GUI apps, under the identity of the interactive user (the guy who sits at the machine). But the apps that our customers write are not always like that. In many cases, they run in hosted environments, such as Windows Service, or a Web app under IIS, etc. There, the identity and the permissions of the principal that runs the OPC client part is different, and that naturally means that DCOM must be configured for that differently.

In addition, we have settings in the product to cover for different security scenarios. If you have established that there are no issues related to the identity and permissions of the principal used to run the client (see above) - but only after that - it may be necessary to tweak these settings. This is described e.g. here: www.opclabs.com/forum/connections-reconnections-com-dcom/124...-remote-machines-via-code#1392



Questions:
1. Are you saying that you get this "Access denied" error only when very high number of items are involved, and that you get no error when the number of items is low?
2. What is the Source in the returned exception object? - is it empty, or does it contain the ProgID or CLSID of the server?
3. What kind of project are you creating with QuickOPC? Is it e.g. Windows Forms or WPF app, a console app, Windows Service, Web, Web service, …? (Reason for the question: They are hosted differently which implicates different security environment which is in turn related to possible "Access denied" error).
4. You have shown a Softing client browsing, but you have not stated a) whether that's from the same machine as where the OPC client runs, and b) what happens when you use the Softing client to write to the same items you are attempting with QuickOPC - does that work, or do you get an error?
5. Conversely, if you attempt to do the browsing (or get properties) with QuickOPC - i.e the things you have demonstrated with Softing client - do they work, and if not, what error do they give?

Best regards
Zbynek

I do not have this information.

Thank you. I really need an answer to questions #6 and #7 before continuing.

Hello.

There are no hard numbers on what is and what is not supported. There are many factors that contribute to the performance, therefore each situation needs to be tested individually.

Operations inside QuickOPC are actually performed on a thread (or threads) separate from the calling thread, and the information is passed between the threads using queues. There are limits on the maximum queue lengths, and on the time operations may take (timeouts). These limits and timeouts are configurable (can be increased if so needed), but one should first establish the facts and determine the cause of problems before doing so. BTW, 40.000 items in one operation is quite high - certainly not something that can be performed in a short moment.

1. What QuickOPC version and build you are using? (tip: Start the installation program you have used, and take these form the first page of the wizard; then abort the installation).
2. Which OPC server are you using?
3. Is it located on the same as the client application, or remotely?
4. How long does it take before the WriteXXXX methods returns, when used with 700 thousand items?
5. How long does it take before the WriteXXXX methods returns, when used with 40.000 thousand items?
6. Please describe in detail what you mean by "…method call returns "Failure" for each field ". If you are getting a non-null value in the .Exception property for the results in the returned array, what does it contain? What is its error message? If it has an InnerException, what is that inner exception?
7. I do not understand this: "When we were testing this, we got that it worked for almost 10 minutes when invoking method from OPC client to push the data. One possible explanation is that this is because it is not sending to "real" OPC server, and that it will work OK. " - in terms of English, and also not factually. Can you try to reformulate it better please. Specifically, I do not understand what you were doing differently from the other situation, what does the 10 minutes refer to, and what do you mean by an OPC server that is not "real".

Best regards