CloseSecureChannel not preceded by CloseSession when disconnecting from within onSessionInactive

[FSangouard]

Hello,

I am seeing a strange behaviour on v0.6.8 and I hope you can help me understand it.

When I call disconnect on a client, I usually see a CloseSession request and then a CloseSecureChannel request go through the network.
But when I call disconnect on a client from within onSessionInactive, I don't see the CloseSession request on the network, only a CloseSecureChannel request.
On the server side, when that happens they tell me the session isn't closed and just expires after some time, which seems to confirm the absence of a CloseSession request.

I tried to look at the code to understand why that is, but I can't figure it out. To me it looks like the session should be closed in every case.

Is that expected behaviour?

[kevinherron]

This is intentional. If onSessionInactive() has been called the state machine has transitioned away from the Active state.

This means either:

• your Session was just closed
• you lost your connection to the Server (not via disconnect())

In either case there's no CloseSession call attempted because either you don't have a Session to close or you just lost your connection and it will fail.

[kevinherron]

Note to self:

Configuring CreatingWait and ReactivatingWait (dev/1.0) states so that they transition to Closing instead of Inactive should result in CloseSession being attempted - but do we want this probable delay that will occur when the Server is offline?

milo/opc-ua-sdk/sdk-client/src/main/java/org/eclipse/milo/opcua/sdk/client/session/SessionFsmFactory.java

Line 192 in d5a2615

fb.when(State.CreatingWait).on(Event.CloseSession.class).transitionTo(State.Inactive);

milo/opc-ua-sdk/sdk-client/src/main/java/org/eclipse/milo/opcua/sdk/client/session/SessionFsmFactory.java

Line 891 in d5a2615

fb.when(State.ReactivatingWait).on(Event.CloseSession.class).transitionTo(State.Inactive);

[FSangouard]

OK, I see. Thank you for your quick reply!

In my case, it happens that the server doesn't respond to Keep Alive requests in time although the session is not closed and the connection is not lost. Of course the solution would be to adapt the Keep Alive timeout or to improve the server's response time, but I wonder if it would be possible and harmless to send a CloseSession request "just in case" ?

[kevinherron]

Yeah, I will ponder on this a bit. It may cause an undesired delay when the server is offline.

In any case this kind of behavior change would probably be made in dev/1.0 and not the 0.6.x series, which is in stable/maintenance mode.

[kevinherron]

@FSangouard In the meantime you can play with the keep alive to prevent unnecessary disconnects, and you can configure a reasonably short Session lifetime so that if you do end up abandoning a Session it won't live long on the server.

It seems to me that calling disconnect() inside onSessionInactive() should be a corner case though - are you trying to manage the connection yourself instead of letting it reconnect automatically?

[FSangouard]

The automatic reconnect does work, however I need to handle the case when the server switches to its backup instance, which is something that happens frequently. In that case I can't rely on the automatic reconnect since it will only try the same instance again, so I have to disconnect/reconnect.

I initiated a discussion about this a year ago (time flies) : #1227

I suppose there hasn't been any changes in that regard?

[kevinherron]

No changes re: redundancy support, but it seems likely that adding support for Servers that implement non-transparent redundancy to the OPC UA Client functionality of our product at work will be a requirement this year, so I'll have a chance to really wrap my head around this problem and figure out if any changes are needed to support it.

[kevinherron]

@FSangouard I'm tracking this in #1413 now, but I've kind of just convinced myself it's not necessary again.

Quoting myself from that ticket:

I think the underlying issue, that Sessions could accumulate when we reconnect due to a keep-alive failure, is solved now that we attempt to re-activate the prior Session before creating a new one.

I think this won't really be an issue any more in 1.0. It would be really helpful if you could try it out and confirm that somehow...

[FSangouard]

I will try to find some time, I won't be in office next week so maybe after that, but I can't promise anything.

[kevinherron]

No problem. I did end up merging the hybrid solution mentioned in #1413:

Maybe something in the middle...

• disconnecting while in ReactivatingWait would attempt to close the Session, since presumably it still exists.
• disconnecting while in CreatingWait would go straight to Inactive, since presumably it does not exist.

Still would be useful for you to test with 1.0 eventually. May 1 is the potential release date right now if I can navigate all the Eclipse Foundation processes without too much delay.

[FSangouard]

Hello again, congrats on the release of v1.0.0 !

I haven't had time to run any tests yet, I would like to give it a go but with all the changes introduced in 1.0.0, I was just wondering if there were any instructions, tips or caveats to upgrade from 0.6.x ?

For example it seems there is no longer a SubscriptionListener for clients, and I wonder if it's been replaced or simply discarded.

[kevinherron]

There is still a SubscriptionListener interface defined inside the new OpcUaSubscription class.

The Client API for doing Subscriptions and MonitoredItems was pretty thoroughly reimagined for 1.0. Best to look at the examples and tests to see how it's used now.