In the original post, there seem to be some misunderstandings about what the purpose of the LogEntry event is, and how it works. I will try to explain this.

Try to think about the QuickOPC (OPCData) as a kind of service - because it is, in fact. It is not a "computational" library where a call from your side would always cause a precise sequence of downstream effects. The service does some things even your code does nothing - e.g. manages the connections/reconnections/disconnections. Conversely, if your code makes a call, what precisely happens depends on the state of the service (we call it "the engine" internally) - so for example, calling a Read may cause the engine to connect to the server, if it is not connected yet; but it may not do it, because the connection already exists; or it may return an error right away, because the server has failed just recently and the reconnection period has not yet passed.

For the reasons just described, it is misleading to think that the events produced by the LogEntry event would be directly tied to readings/writing you perform. There will be *some* correspondence, but not precise. For example, when you instantiate the first EasyUAClient, multiple things will happen that relate to setting up the engine, and they will not be repeated when the second instance is created. Similarly, when you perform a first Read, there will be many things related to creating the connection, and even some application-wide tasks (also related to certificates!) that will not necessarily be repeated for the second Read, because the connection and other supporting will already be there, ready to use. On the other "end", the operations of the engine may survive some time over the lifetime of the last EasyUAClient instance - for example, a connection to the OPC server might be held open, for optimization purposes, for some time. That's why it is more appropriate to think about the component as a "service".

This also explains why the event is a static event, and not an instance event - it is not a design mistake, it has to be that way.

In addition, the LogEntry mechanism is not (at least currently) meant as detailed troubleshooting tool for low-level communications between the OPC server and the OPC client. One reason for it is the performance impact it could have. As such, it will *not* actually log anything about the actual Read or Write call to the OPC server, unless there is some kind of problem that the OPC UA compliance requires be logged.

Going back to the specifics of your questions:

1. Breaking up the events by instance: Given the principles I explained, I am afraid that this cannot be done.
2. "When we encounter an error with a read or write..." - be aware that "normal" errors (such as when the server returns a "Bad" status code for the operation) will *not* show up through LogEntry at all. But connection-related problems, and also the certificate-related info (which you were mostly after) will be there, yes.
3. "is there a good place that you recommend that we register for the LogEntry event?" I will need to know the kind of application we are talking about (e.g. a desktop app/Windows service/Web service etc.). But the general recommendation would be to hook the event as soon as possible, and unhook as late as possible, in relation to the global lifetime your app - not to tie it to anything that goes in and out. It seems that you try to avoid doing it this way - if so, please describe the reasons for it, I can then comment (or provide some alternative suggestion).

Best regards

Hello...,

...we were talking ... about subscribing to the OPC events you send out to try and get better logging for our application. We have recently started looking seriously into implementing this, and had a few questions about what we need to do.

The EasyUAClient LogEntry event is a static event that gets logged for any kind of reading or writing that goes on, but for our purposes we need to be able to designate between which client is performing the read. On all of our machines, we have anywhere between two and four windows up at a time that are all reading and writing data from OPC. When we encounter an error with a read or write, we would like to know which of these clients is throwing the event at hand, especially for errors, but I don't think I see any properties in your LogEntryEventArgs that can be used to do this. Is there a good way for us to detect this? Essentially our log files are broken up by instance so we would like to break up events in the same way if we can.

Also, is there a good place that you recommend that we register for the LogEntry event? We only really want to do this when we have an instance of EasyUAClient out there somewhere and I think it makes sense to unregister from the event when the EasyUAClient is gone. I'm a little concerned that if we put this in the wrong place we're going to have a problem with memory leaks and redundant logging of errors. Similarly, it would consume a lot of resources if we register and unregister the event with every read and write. I don't think we necessarily know when an EasyUAClient is discarded to unregister the events beforehand either.

Thanks for your continued support,

[Note: relates to opclabs.com/forum/ua-connections/1309-ua-client-certificates#1685]