Question
Selenium Grid 4 session persistence limits during incremental migration
Dev Cedar
0 reputation · 06 Feb 2021, 16:43 UTC
106.7K views1
Loading…
0 reputation · 06 Feb 2021, 16:43 UTC
We are planning to migrate a small Selenium Grid deployment to Grid 4 incrementally, with the goal of avoiding interruptions to in-flight browser sessions. The documented architecture separates the Router, Distributor, Session Map, and Node processes, and nodes support graceful draining so running sessions can finish before a node exits. However, the Session Map defaults to an in-memory store, while a JDBC-backed store is available for persistence across restarts.
The unresolved behavior is how much failover state the default configuration actually preserves. If the Distributor or Session Map restarts while using the default in-memory map, in-flight session records may be lost, leaving the Router unable to route to sessions it no longer tracks. The documentation describes graceful drain and external session storage, but does not guarantee automatic failover of the Router itself. Because Grid 4 replaces the Grid 3 hub/node model, existing configurations and flags do not carry over unchanged.
Does a Grid 4 migration require an external session store and multiple Router instances to avoid session loss, or can the default in-memory map tolerate component restarts in a small setup? What is the documented failover boundary between node draining and Session Map persistence? Are there version-specific differences across 4.x releases that change which session map backends are supported?
34775 reputation · 07 Feb 2021, 00:29 UTC
No. The default in-memory Session Map does not survive a Distributor or Session Map restart. If either process restarts, session records are lost and the Router can no longer route to in-flight sessions. You need an externally backed Session Map, typically JDBC, if sessions must survive component restarts. Running multiple Router instances improves Router availability, but it does not preserve session state by itself; the Routers still depend on a persistent Session Map.
Grid 4 separates the legacy hub into Router, Distributor, Session Map, and Node. The Session Map is the authoritative record of which session runs on which Node, and the Router consults it for session requests. With the default in-memory implementation, that record exists only in the running process heap, so a restart wipes it. Node graceful draining is a different boundary: it lets a Node finish existing sessions before exiting, but it does not replicate or restore Session Map entries. Draining therefore cannot prevent session loss caused by a Session Map or Distributor restart.
This answer assumes you are running Selenium Grid 4.x as standalone Java processes and that incremental migration means upgrading or restarting Grid 4 components while preserving sessions. Exact JDBC syntax, optional backend plugins, and supported backends vary between Grid 4.0, 4.1, and later 4.x releases. Those version-specific details require verification against your release notes before you apply the configuration.
With the default in-memory Session Map, restart the Distributor or Session Map process and check Router logs for indications that previously active sessions can no longer be located. After enabling a JDBC-backed Session Map, repeat the restart and confirm sessions remain routable. You can inspect your configuration file with a command such as:
seleniumgrep -n "session" grid-config.tomlReplace grid-config.toml with your actual Grid configuration file path.
Which Grid 4.x version are you targeting? Supported session map backends and configuration flags differ across releases, and this changes the exact migration steps.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 06 Feb 2021, 22:56 UTC
To further clarify the boundary between node draining and session persistence: it is important to note that graceful draining is a Node-level state, whereas the Session Map is a Distributor-level record. Draining ensures a Node finishes existing browser sessions before shutting down, but it does not protect the session's routing metadata.
If you are using the default in-memory map, a Distributor restart wipes the routing table regardless of whether the Nodes are draining or fully active. In this scenario, the browser session may still be physically alive on the Node, but the Router loses the pointer to it, resulting in a "session not found" error for the client.
For those migrating incrementally, you can verify this behavior in a staging environment by:
If the command fails despite the Node remaining online, it confirms the need for a JDBC-backed store to maintain routing continuity.