Dormant Clients

I still fail to understand why Ignition does not auto close dormant clients, I thought they were supposed to close out after a few minutes of being dormant? I came in to over 100 dormant clients from the same station.

I’m also curious what causes this. We usually don’t have any issues, but yesterday got a support call from an operator trying to login and on a four client limited license. There were two active clients and two dormant ones, with the dormant ones being clients he had closed to re-open due to a nuisance quality overlay bug. Having to wait a minute after closing a client for the license to free up isn’t unusual, but these ones didn’t seem to want to go away even after several minutes. I had to end them from the gateway before the operator could login. v8.0.16.

This was basically just a bug - it’s fixed in 8.1.1. Unfortunately I don’t think it’s likely to be backported to 7.9.

1 Like

That’s good to hear; planning to upgrade soon.

Note that for upgrades, you’ll have to “opt-in” to the new behavior - it’s in the Gateway -> Security settings, but defaults to 0 for upgrades.

2 Likes

Were you referring to the inactivity timeout in Config->Security->Identity Providers->ProviderName->Settings?


Would “inactivity” in this context refer to lack of communication from client (as opposed to user inactivity on client)?

Or am I looking in the wrong place?

Just Security -> General -> User Inactivity Timeout. Vision client session should go through the same bookkeeping as the gateway’s sessions. IdP inactivity timeout is the same idea, but specific to the identity provider keeping a logged in session alive - HTTP sessions at the Jetty level are distinct from actual logged in sessions.

You can also give this a try.

Killing a Dormant Session in an Ignition HMI