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.
Not sure the bug is fully fixed. We are using 8.1.36 and had over 400 'dormant' clients on one machine this morning.
We ended up rebooting the 'dormant' client machine, but Ignition still showed over 400 dormant clients on the rebooted machine.
Ultimately we rebooted our primary Ignition server to clear out the dormant sessions.
We have since set the inactivity timeout to 5 days (7200 minutes) to hopefully mitigate future occurrences. We hope this does not affect display clients we use for dashboard data.
Increasing the inactivity timeout seems like exactly the opposite of what I would recommend. I would recommend contacting our support department officially so they can do a proper investigation and see what might be going wrong here.