Client Sessions and Timeouts
The ADITO Web Client holds its user interface state on the server. A session therefore exists as long as the server has reason to believe that the browser is still there and that a person is still working with it.
This page describes the heartbeat that keeps a session alive, the parameters that end it, and how those parameters interact. It is the reference for planning session lifetimes and for interpreting timeout entries in the log.
How the Heartbeat Keeps a Session Alive
Every open browser tab sends a small sign of life to the server at a fixed interval, the heartbeat. The heartbeat is not a timeout in itself. It is the clock that the other values are derived from and compared against, and it is the only call that still arrives while a user is idle.
Two consequences follow from this:
- Only real HTTP calls keep a session alive. An open WebSocket connection does not, because it carries the push channel rather than the client's requests.
- If a tab stops executing JavaScript, the heartbeat stops immediately. Anything that freezes or disconnects the tab therefore starts the timeout clocks, no matter whether the user considers the tab open.
Timeout Parameters
| Parameter | What it measures | Effect when it is exceeded |
|---|---|---|
neonHeartbeatInterval | Nothing. It is the clock source, with a default of 50 seconds. | Three times this value is the period after which a single browser tab is considered dead on the server. |
clientTimeout | The time since the last real user action, such as a click, an input, or navigation. Heartbeats explicitly do not count as user actions. | The entire client session is ended and the user is signed out. Logged as USER_TIMEOUT. Default: 24 hours. |
clientMaxIdleTime | The time since the browser last contacted the server. Every call counts here, including a plain heartbeat. Four times the configured value takes effect. | The entire client session is ended. Logged as CONNECTION_TIMEOUT. Lower bound: 30 minutes, smaller values are raised to that. |
neonIdleTimeout | The same clock as clientMaxIdleTime, that is, the time since the browser's last contact. | The HTTP session in the web server expires, and the client session is cleaned up shortly afterwards. Default: 45 minutes. |
clientTimeout is configured in the Designer under ____CONFIGURATION > System > Client. The other values belong to the Instance Configuration.
How the Timeouts Interact
The parameters fall into two groups. clientTimeout watches the person, so it asks whether anybody is still working. clientMaxIdleTime and neonIdleTimeout watch the browser, so they ask whether the client is still reachable at all.
clientMaxIdleTime and neonIdleTimeout read the same clock, which means the smaller effective value always wins. Because the connection timeout cannot fall below 30 minutes and neonIdleTimeout lies above that by default, the connection timeout is what takes effect in practice. Raising neonIdleTimeout on its own therefore has no effect at all.
The server does not evaluate the timeouts to the second, it checks every 5 minutes. Up to 5 minutes can therefore be added to any of the deadlines above.
The idle timeout of the WebSocket connection is fixed at one hour and is unrelated to session lifetime. It applies to the push channel for server notifications only and never ends a session.
Lifetime of a Single Browser Tab
A session can span several browser tabs, and a tab has its own, much shorter lifetime than the session it belongs to.
Once no heartbeat has arrived for three times the heartbeat interval, the server considers that tab dead. Whether its user interface is actually torn down depends on when the server next has a reason to clean up, because cleanup runs on incoming calls of the session rather than on a timer of its own:
- The session has only this one tab: nothing happens for the time being. The next call of the session is the tab reporting back after it becomes active again, so the interface is still there and the user notices nothing.
- The session has another active tab: its calls trigger the cleanup, and the interface of the dead tab is torn down on the server. When that tab becomes active again, it rebuilds its interface, which takes a few seconds. The session and all open data are preserved, and the user stays signed in.
Losing a tab's interface is therefore not the same as losing the session. Only the two session timeouts end a session, and both of them log the reason:
| Log entry | Meaning |
|---|---|
USER_TIMEOUT | The session was ended because no user action occurred within clientTimeout. |
CONNECTION_TIMEOUT | The session was ended because the browser did not contact the server within the connection timeout. |
Configuring Longer Deadlines
If sessions have to survive longer periods without contact, raise clientMaxIdleTime and neonIdleTimeout together, so that the resulting deadline covers the expected gap. Remember the factor of four when calculating clientMaxIdleTime, and remember that raising only one of the two values has no effect.
Longer deadlines also delay the detection of clients that actually crashed or were closed. Those sessions keep occupying a license until their timeout has elapsed, so raise the values only as far as the use case requires.
A common reason for hitting the connection timeout is a browser that puts inactive tabs to sleep, which stops the heartbeat without the user noticing. In that case, exempting the application from tab suspension is the better remedy, see Client - Background Tabs.