Hi K.

I have investigated the two issues. Big parts of the report (and the code, probably) appear to be written in AI, and frankly, it is difficult to understand (this seems to be common problem with bug reports these days, as I know from other developers). But I think I got the gist of it.

Both issues they reported are genuine, and should be fixed now.

Thanks to you & the customer for reporting them!

Please rebuild and retest with OPC Data Client/QuickOPC 5.84.416 (or later). The NuGet packages are on nuget.org. For the full installer, I will send you the link by email.

Best regards
 

Hey Z,

Sounds like a plan, thank you for the quick reply!  I hope you have a great week at the interop!

Best Regards,

Hello K.,
good to hear from you after some time.

Thanks for the report, From reading the text (I have not opened the attachment yet), unless there is some error in the repro code, those look like genuine issues that need to be fixed on QuickOPC side. 

I will investigate. However, I am on the OPC Interoperability Workshop this week, busy with other tests, and I will be in OPC UA workgroup meeting next week. I apologize, but I will not be able to look into it during these 2 weeks, most likely. But I will definitely address it then. 

Thank you for understanding.
 

Hello Z,We are working with a client who may have identified some possible growths.  I’m sending a small standalone .NET Framework console project and its README for your review. It reproduces two memory retention issues we’re seeing with QuickOPC. The project does not require access to our application, an OPC UA server, or any configuration. On QuickOPC 5.84.374, running the executable without an endpoint takes about 4½ minutes and reports the result of each check.The first issue concerns OPC UA read results. Our long-running service grew to about 10 GB of memory after 57 days. We found that objects returned by appear to remain attached to a cached result’s diagnostics collection after the caller discards them. The reproduction creates 100,000 discarded results and shows that they remain alive while the cache entry exists; removing that entry releases them.The second issue concerns client disposal. In the reproduction, 100 instances are created, used, and disposed one at a time. All 100 remain alive after a full garbage collection, even when connection attempts fail because no server is present. In our service, the number of retained client chains has also increased with each client created and disposed.The README includes build and run instructions, expected output, production observations, and the object paths we found while investigating. Our explanation of the internal causes is a hypothesis based partly on decompiled assemblies, so we would appreciate your assessment of it.Could you confirm whether these are QuickOPC defects? For each issue, is there a fix or a supported way to prevent or bound the memory growth?