Hi, no need to apologize. In fact this part is not as obvious as I wish it to be, but I still struggle to satisfy the "user-friendliness" requirement while keeping a technically reasonable underlying design.

Some more notes:

- The same should work from the Properties window on the EasyUAClient component - if it does not, there may be a problem somewhere.
- Please let me know if setting the HoldPeriod to Timeout.Infinite works. I know you cannot wait infinitely long to prove that it works but it should not fail and should keep the connection open.
- On the other hand, I can't imagine why "infinite" should be truly needed, because your app must be doing something to that server at some point time, or not?
- You can also hold the connection open by subscribing to some *other* node.
- The requirement for better control over the connections/disconnections is a recurring one. I plan to look at it seriously in some future version. But it kind of goes against the principles we have built upon, so it will be tough to integrate the two.

Best regards

Let's first explore it with the code, and leave the Properties window for later.

In order for the easyUAClient1.IsolatedAdaptableParameters to work, you also need to set easyUAClient1.Isolated = true. Have you done that?

Can you please post the code you use to set the parameters, incl. HoldPeriod, and the version/build number used?

You can use the UA Compliance Test Tool (CTT), it does a job similar to OPC Analyzer. it has some limitations, though (such as it only does OPC.TCP, and it limits the security options).

If you do not need all details, you can just hook to the static EasyUAClient.LogEntry event, and observer the events there. There are events generated for opening/closing sessions.

What is the particular reason for the need to keep the session permanently open?
We haven't designed for this, but it might be possible, with the "infinite" hold period, but I need to check.

Best regards

The expected behavior is roughly as follows:

Whenever something from the server is needed, a session is "requested", and its usage count incremented; when it is no longer needed, the session is "released", and its usage count decremented.

"Something needed" mentioned above may be a one-shot operation (e.g. Read, or Write, and others). In this case the session is requested, the operation performed, and then released. Or, it may be a Subscribe; in such case, it does just the request part, and Unsubscribe does the release part.

Whenever the usage count goes from 0 to 1, the connection is attempted.
Whenever the usage count goes back from 1 to 0, the connection is closed - but possibly not immediately; it may be closed after a so-called "hold period" or a bit later.

There is "garbage collector" thread that goes over all existing sessions, and closes those that are no longer needed (their usage count is zero) AND are after their hold period.

The default hold period is 5 seconds; the default period (frequency) of the garbage collector is 2 seconds. This means that by default, an unused session should be closed after 5 to (5 + 2) = 7 seconds of inactivity. It should not matter whether that "inactivity" means "one or two reads", or "unsubscribe from everything".

If you do see something that does not conform to this expected behavior, please let me know.

Best regards