What are the six components of a fully distributed Selenium Grid 4 deployment?
answer
- Grid 4 is not one process
- Count the selenium-server subcommands
- One entry point, one matcher, one lookup table
- There is a queue and a message channel
- Plus the process that owns the browsers
basics
~20 sRouter, Distributor, Session Map, New Session Queue, Event Bus and Node. In Selenium 4's fully distributed topology each is a separate process with its own subcommand and port, so each can be sized and restarted on its own.
solid answer
~40 sSelenium Grid 4 breaks the old single hub into six roles, each startable as its own `selenium-server` subcommand. `router` on 4444 is the single entry point clients address; `distributor` on 5553 tracks Nodes and creates sessions; `sessions` on 5556 is the Session Map holding session id to Node URI; `sessionqueue` on 5559 is the holding pen for new session requests; `event-bus` carries internal messages on 4442 and 4443; and `node` on 5555 owns the browsers and runs the commands. A new car-rental pickup-form session goes client to Router to New Session Queue, the Distributor polls the queue and picks a matching Node, then writes the session into the Session Map so the Router can forward every later command straight to that Node.
go deeper
Be ready to name all six roles and say in one line what each owns. Interviewers use this as a check that you know Grid 4 is not a single hub program with a flag.
Explain the request path through the six and know each default port: Router to queue, Distributor polls and matches, Session Map records the Node, Router forwards later commands.
Show which components hold state, which are safe to restart during a run, and which flags wire them to each other once they sit on different machines.
Own the question of whether six processes are worth their operational surface at all, and what the split lets you resize or replace independently later on.
## What "fully distributed" actually means Selenium Grid 4 is not one program with a hub switch. The work that older Grids packed into a single **hub** process was broken into six independent roles, and the `selenium-server` jar can start each one on its own. Running all six as separate processes is what the Selenium documentation calls the **Distributed** topology, as opposed to **Standalone** (everything, browsers included, in one JVM) or **Hub/Node**. The six roles are the **Router**, the **Distributor**, the **Session Map**, the **New Session Queue**, the **Event Bus** and the **Node**. ## What each of the six owns - **Router** — the only component your test code addresses. It is the front door: a new session request is handed to the New Session Queue, and a command for an already-running session is forwarded straight to the Node holding it. - **Distributor** — keeps the picture of which Nodes exist and what slots they offer, in a `GridModel`. It polls the New Session Queue, matches a pending request against a free slot, asks the Node to create the session, and records the result. - **Session Map** — a lookup table from session id to the URI of the Node running that session. Nothing else: no test output, no logs, no screenshots. - **New Session Queue** — the holding pen for new session requests that have arrived but do not yet have a slot. - **Event Bus** — the internal message channel. Grid does most of its component-to-component signalling as messages here instead of as HTTP calls. - **Node** — owns the browsers and drivers on its machine and executes the WebDriver commands handed to it. A Node makes no decision about which request it should receive. ## Subcommands, default ports and bus membership | Role | Subcommand | Default port | Joins the event bus? | |---|---|---|---| | Router | `router` | 4444 | no | | Distributor | `distributor` | 5553 | yes | | Node | `node` | 5555 | yes | | Session Map | `sessions` | 5556 | yes | | Event Bus | `event-bus` | 5557 over HTTP, 4442 and 4443 for messages | it *is* the bus | | New Session Queue | `sessionqueue` | 5559 | no | Two spellings catch people out. The Session Map's subcommand is `sessions`, not `sessionmap`, even though the class behind it is `SessionMapServer`. The Event Bus's is `event-bus`, with the hyphen. ## One car-rental pickup-form session, end to end 1. The suite asks the **Router** on port 4444 for a Chrome session to exercise the car-rental pickup form. 2. The Router passes the request to the **New Session Queue** over HTTP and waits for a response. 3. The **Distributor** polls the queue, takes the request, and looks for a free slot whose stereotype matches the requested capabilities. 4. The Distributor asks the chosen **Node** to create the session; the Node starts the browser and returns the session details. 5. The Distributor writes the session id and that Node's URI into the **Session Map**, and the response travels back out through the queue to the Router and on to the client. 6. Every later command — type a pickup date, click the search button — arrives at the Router, which reads the Session Map to learn the Node URI and forwards the command directly to that Node. 7. When the test quits, the Node publishes a session-closed message on the **Event Bus**; the Session Map is subscribed and drops the entry. ## Start order, and why it is not arbitrary The Event Bus comes up first, because the Distributor, the Session Map and every Node connect to it while they start. The rest can follow in any order, though the Router is usually last so that a client cannot reach a Grid that has nothing behind it yet. ```bash java -jar selenium-server.jar event-bus --publish-events tcp://10.0.0.5:4442 --subscribe-events tcp://10.0.0.5:4443 --port 5557 java -jar selenium-server.jar sessionqueue --port 5559 java -jar selenium-server.jar sessions --publish-events tcp://10.0.0.5:4442 --subscribe-events tcp://10.0.0.5:4443 --port 5556 java -jar selenium-server.jar distributor --publish-events tcp://10.0.0.5:4442 --subscribe-events tcp://10.0.0.5:4443 --sessions http://10.0.0.6:5556 --sessionqueue http://10.0.0.8:5559 --bind-bus false --port 5553 java -jar selenium-server.jar router --sessions http://10.0.0.6:5556 --distributor http://10.0.0.7:5553 --sessionqueue http://10.0.0.8:5559 --port 4444 java -jar selenium-server.jar node --publish-events tcp://10.0.0.5:4442 --subscribe-events tcp://10.0.0.5:4443 ``` ## Three things this split is not - **Not six machines.** Six processes on one host is a legitimate, if pointless, distributed Grid. The split is about process boundaries, not hardware. - **Not a hub plus five helpers.** There is no hub process in this topology at all. `hub` is a separate subcommand that bundles five of these six roles into a single JVM. - **Not extra browser capacity.** Slots still come from Nodes, and a suite that waits because every Chrome slot is busy gains nothing from running the other five roles apart.
- Which of the six does a Node itself need to reach?Only the Event Bus, which it connects to with the publish and subscribe addresses it is given. Everything else reaches the Node inbound over HTTP: the Distributor to health-check it and to create sessions, and the Router to forward commands. A Node never talks to the Session Map or the New Session Queue.
- What exactly does the Session Map store, and who writes to it?The session id and the URI of the Node running it. The Distributor writes the entry once a session exists, the Router reads it on every forwarded command, and the map removes entries itself when it sees a session-closed, node-removed or node-restarted message on the event bus. It holds no test output.
A hub is a one-room rental office where the front desk, the dispatcher, the key cabinet and the waiting-list clipboard all share a table. Going distributed gives each of them its own room and its own door.
saying these in an interview costs you the question
- Calls the Router a load balancer that picks the Node itself
- Thinks a Node registers with the Router rather than the Distributor
- Says the Session Map stores test results or screenshots
- Believes the six components must run on six machines
- Treats the hub as a seventh component alongside these six