Since recent browser updates, a number of customers have reported that their MX Web Client session disconnects while they are working elsewhere. This post explains why this happens and describes the options available to resolve it, along with the advantages and disadvantages of each.
The Symptom
Users see a dialog box in the browser:
Title: Connection is lost
Contents: The page will be reloaded to try to establish a new connection
In the browser console, it may appear as:
Closing WebSocket connection code(1001) reason(The WebSocket
session [14] idle timeout expired) clean(Yes)
Connection is lost
This typically occurs after the user has been working in another browser tab, in another application, or with the browser minimised, and then returns to the web client tab.
Why This Happens
Modern browsers now enforce background throttling on inactive tabs. When a tab is not in the foreground, the browser suspends or heavily limits JavaScript execution in that tab.
The MX Web Client maintains a persistent connection to the servlet over WebSockets. To confirm the connection is still valid, the client sends a ping event on a timer. The default interval is 1,200,000 milliseconds (20 minutes) and is configurable through the ws_ping_interval setting in the web client configuration settings.
The servlet listens for these pings. If three consecutive pings are not received, the connection is closed and the session is ended. This is deliberate: it prevents sessions from lingering when a client has genuinely disconnected, for example after a network failure where the client cannot signal that the connection is ending.
When the browser throttles the background tab, no JavaScript runs, so no pings are sent. The servlet sees the missed pings and closes the connection. The user only discovers this when they return to the tab.
Some browsers offer a feature to whitelist sites and exempt them from throttling. In practice we have found that this list is either no longer available or does not prevent throttling completely, so the issue still occurs.
Option 1: Increase the Ping Interval
Configure ws_ping_interval to a much longer period, for example 4 hours. Because the connection is only closed after three missed pings, a disconnect would not occur within 12 hours — typically enough for a full working day.
Advantages
- Simple configuration change on the server side.
- No action required from end users.
Disadvantages
- Sessions may linger for a long time when a connection is genuinely broken, holding resources until the extended timeout expires.
- Some customer networks include components that drop connections that are idle for a set period. Reducing the ping frequency means less traffic on the connection, which may cause such components to disconnect the session prematurely.
Option 2: Install the Page as an Application
Modern browsers can install a web page as a standalone application. Pages installed this way are not subject to background tab throttling, so ping events continue to be sent even when the window is minimised or running in the background.
Google Chrome: menu → Cast, save and share → Install page as app
Microsoft Edge: menu → More tools → Install this site as an app
Advantages
- Addresses the throttling at source — the ping continues to be sent normally.
- No server-side configuration changes required.
Disadvantages
- Each end user has to install the site as an application on their own machine, which adds a rollout and support step.
Option 3: Configure Session Resume
Session resume avoids requiring users to install anything. With session resume configured, the session is parked on the engine and the servlet when a disconnect occurs. The connection is still broken, but when the user returns to the browser tab the reconnect succeeds and they are redirected back into their existing session.
What needs to be configured
- The engine and the servlet both need to be configured for session resume.
- ClientAliveCheckTime sets a session timeout — how long a session is kept available for restore after a connection is lost. A longer value retains the session longer but occupies that memory for the duration. The best value depends on how your system is used and what your users require.
Session IDs
Session resume requires each session to pass a unique ID. This can be supplied in the URL, or generated by a piece of server-side script such as a JSP page that determines a unique session ID.
- If a user only ever has one session, the ID can be bound to their user ID.
- If users need multiple concurrent sessions, another mechanism is needed. For example, users can keep several bookmarked URLs for their different sessions, use an entry page, or have the session IDs generated dynamically in a JSP page.
Session IDs must be unique per session. Unless configured otherwise, the application checks both the browser ID and the session ID, so a session ID will only work when used from the same browser. It cannot be used from another machine to restore the session.
A note on using UUIDs
It is possible to use a generated UUID as the session ID. This is always unique and allows users to open multiple sessions, but it has a side effect worth understanding. When a connection is lost and restored, the same UUID is reused and the session resumes correctly. However, if the user refreshes the page and a new UUID is generated, a new session is created and the old session stays parked until its timeout expires, because the original UUID is never reused to reconnect.
Which Option Should You Choose?
- Increase the ping interval — quickest to deploy, and a good fit where the network does not drop idle connections and lingering sessions are not a concern.
- Install as an application — the most direct fix for the throttling itself, suited to environments where a one-off setup step can be rolled out to users.
- Configure session resume — the most robust option for users who regularly leave the client in the background, at the cost of additional configuration and a session ID strategy.
Summary
The issue can be addressed in several ways, each with its own advantages and disadvantages. There is no one-size-fits-all solution, so we recommend choosing the approach that best suits your environment and your users’ requirements.
If you are unsure which option fits your deployment, reply to this post or contact support and we will be happy to advise.
