Hello. The build that has a fix for the problem we have found is now on the public Web, in the download area (it announces itself as 5.12.1392.1).
Thank you for cooperation, hopefully this will resolve your problem.
Best regards

We have found a memory leak with InvokeXXXX methods. In our analysis, it would only appear if there was an error performing this operation (no leak if it went successfully). There may also be a related thread leak (not confirmed yet).
We are working on further analysis and a fix for this. Please wait for next post.
Regards,

This kind of check is up to your application. It should not be part of the component, because in general case, writing to OPC items that exhibit Bad quality upon reading is not an invalid operation, and depending on the OPC server, it may even have a specific meaning and intentionally be used. In addition, the Read and Write cannot be performed together as one atomic operation through OPC interfaces, and if there is a problem at one moment, it may be gone a moment later.

We do not directly log this error, but it looks quite relevant to this problem. It could be that either our process, or something else in the system, is consuming the threads. I will try to see if this can be related to InvokeXXXX method.
On your side, with this particular error, it is very important to determine which process is responsible for this. You should set up either task manager or process monitor and observe/log the number of threads consumed by each process.

From: .....
Sent: Monday, September 10, 2012 11:21 AM
To: Zbynek Zahradnik
Subject: OPCLabs forum - new post, update

By the way,

Our log file has catched the error:
“No more threads can be created in the system” several times, seems like it has been logged after “InvokeWriteItemValue” to the system with no communication.
Does this error come from OPCLabs?

Thank you. The fact that you are using InvokeWriteItemValue is new to me. Calling this methods has not been included in the test made earlier.
Can you quantify how many calls to this method, and with how many items, can accumulate over time? We can make a test with this method as well.
The queue sizes should rather be set higher, not lower. If a queue is filled to the limit at any moment, it means a serious problem because the system is not coping with the load, and notifications get lost.

Hello,
we have set up a long-running test with following parameters:

QuickOPC-COM 5.12.1305.1
queue sizes increased according to your picture
client test application subscribing to 12,000 items
each item changing on the server once in 10 minutes (in a phased manner), giving an average rate of change of 20 changes/second
server failure (with OPC_STATUS_FAILED) simulated every 10 minutes (that's quite often...)

We ran this test for approx 2.5 days, and collected the memory consumption (Private Bytes counter) using Windows performance monitor. Unfortunately, no relevant increasing trend in memory consumption could be observed: The "baseline" stayed around 72-73 MB.
We will continue trying to reproduce the problem with different and more "harder" settings. Can you please answer the following as well:

Is your application also using "one-time" reads and writes, or is it just permanently subscribed as our test application is? Can you describe the general "usage pattern" of QuickOPC methods in your application?
I am still not sure about the setting for "Abandon interval minimum:. Are you running with it checked, or unchecked?

Thank you