Which Selenium Grid 4 components talk only over HTTP and never join the event bus?

seniorshould knowfreq 35%

answer

Not every component needs the bus
Count the bus flags per subcommand
Two of the six stay on HTTP
The front door and the holding pen
Router and queue take no bus flags

basics

~20 s

The Router and the New Session Queue. Neither declares the event bus role, so neither accepts the bus flags. The Distributor, the Session Map and the Node are the bus members, alongside the event-bus process itself.

solid answer

~40 s

Each subcommand declares which configuration roles it accepts, and router and sessionqueue are the two that leave out the event bus role. The Router is wired instead with three HTTP URLs: --sessions for a RemoteSessionMap, --sessionqueue for a RemoteNewSessionQueue, and --distributor for a RemoteDistributor. The queue takes little more than --port; the Router posts requests into it and the Distributor polls it, both over HTTP. That split scopes a bus outage precisely: the Distributor stops hearing about Nodes and the Session Map stops evicting closed sessions, but commands for a car-rental pickup-form session already open keep flowing, because client to Router to Session Map to Node is HTTP the whole way.

Each subcommand declares which configuration roles it accepts, and `router` and `sessionqueue` are the two that leave out the event bus role. The Router is wired instead with three HTTP URLs: `--sessions` for a `RemoteSessionMap`, `--sessionqueue` for a `RemoteNewSessionQueue`, and `--distributor` for a `RemoteDistributor`. The queue takes little more than `--port`; the Router posts requests into it and the Distributor polls it, both over HTTP. That split scopes a bus outage precisely: the Distributor stops hearing about Nodes and the Session Map stops evicting closed sessions, but commands for a car-rental pickup-form session already open keep flowing, because client to Router to Session Map to Node is HTTP the whole way.

code

bash · 7 lines

bash

java -jar selenium-server.jar sessionqueue --port 5559

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

go deeper

for a junior

Know that some Grid components use the message bus and others only use HTTP, and that your tests reach the Router on 4444 either way.

for a middle

Be able to name the two HTTP-only roles and the flags each one takes instead of bus addresses, and say what the Router looks up on every forwarded command.

for a senior

Use the split to scope an outage: say precisely what stops and what keeps working when the bus disappears, and justify it from the actual request path.

for a principal

Own where the trust boundary sits. The Router is the only client-facing role, so authentication and exposure belong there while bus ports stay internal.

Who is on the bus and who is not

Each Grid 4 subcommand declares the set of configuration roles it accepts, and EVENT_BUS_ROLE is one of them. That declaration is the authoritative answer to this question, because a component that does not declare the role does not accept the bus flags and does not construct a bus client.

Subcommand	Roles it declares	Event bus?
`event-bus`	event bus, httpd	hosts it
`distributor`	distributor, event bus, httpd, session map, session queue	yes
`sessions`	event bus, httpd, session map	yes
`node`	event bus, httpd, node	yes
`router`	distributor, httpd, router, session map, session queue	no
`sessionqueue`	httpd, session queue	no

So the two HTTP-only components are the Router and the New Session Queue. Everything they do, they do with ordinary HTTP requests.

What the Router is wired to instead

RouterServer builds three clients from configuration and nothing else:

a RemoteSessionMap from --sessions, used on every command to translate a session id into a Node URI;
a RemoteNewSessionQueue from --sessionqueue, where new session requests are parked;
a RemoteDistributor from --distributor, used by the Grid's own status and GraphQL surface.

Note that SessionMapOptions defaults its implementation to RemoteSessionMap, and throws Unable to determine host and port for the session map server if you start router without --sessions. A hub avoids that only because DefaultHubConfig overrides the implementation to LocalSessionMap and holds the map in its own JVM.

What the New Session Queue is wired to instead

The sessionqueue process is the simplest of the six. It takes --port and its own timeout settings, and nothing pushes into it or pulls from it over the bus. The Router posts a new request to it over HTTP and holds the connection open; the Distributor polls it over HTTP through a RemoteNewSessionQueue and completes the request when a session exists. Two HTTP peers, no subscriptions.

Why the distinction matters in practice

It tells you which flags each process needs. Passing bus addresses to router or sessionqueue is a sign you have not understood the topology; leaving them off distributor, sessions or node breaks the Grid.
It scopes what a bus outage actually breaks. The bus carries Node status and heartbeat traffic to the Distributor and session-lifecycle messages to the Session Map. Lose the bus and the Distributor stops hearing about Nodes, and the Session Map stops evicting entries for closed sessions and departed Nodes.
It explains why running commands keep working. For a car-rental pickup-form session that is already open, the whole path — client to Router, Router to Session Map, Router to Node — is HTTP. Filling in the pickup date and clicking search keeps working while the bus is down; it is new sessions and changed Node membership that stall.
It shapes what you protect. The Router is the only component a client ever addresses, so it is the one that carries --username/--password basic auth and --sub-path. The bus ports are internal and should never be reachable from where your tests run.

Wiring the two HTTP-only roles

Start sessionqueue with just --port 5559.
Start router with --sessions, --distributor, --sessionqueue and --port 4444.
Give both the same --registration-secret as the rest of the Grid if you have set one, since that secret guards the component-to-component HTTP calls, not the bus.
Do not give either of them --publish-events, --subscribe-events or --bind-bus.
Expect router to be the only one of the six a client ever connects to, and keep the other five off any network your test machines can reach.

A useful sanity check when a distributed Grid misbehaves is to count bus flags: exactly four processes should carry an address pair, and seeing one on the router or the queue means somebody copied a command line without reading it.

The answer in one breath

Six components, four bus members. The Router and the New Session Queue are pure HTTP: the Router because it is a forwarding front door that only ever needs a URL, and the queue because it is a passive store that the Router writes to and the Distributor reads from. Being able to say which two, and why each of them has no reason to subscribe to anything, is what separates a candidate who has run a distributed Grid from one who has read the diagram.

## Who is on the bus and who is not Each Grid 4 subcommand declares the set of configuration **roles** it accepts, and `EVENT_BUS_ROLE` is one of them. That declaration is the authoritative answer to this question, because a component that does not declare the role does not accept the bus flags and does not construct a bus client. | Subcommand | Roles it declares | Event bus? | |---|---|---| | `event-bus` | event bus, httpd | hosts it | | `distributor` | distributor, event bus, httpd, session map, session queue | yes | | `sessions` | event bus, httpd, session map | yes | | `node` | event bus, httpd, node | yes | | `router` | distributor, httpd, router, session map, session queue | **no** | | `sessionqueue` | httpd, session queue | **no** | So the two HTTP-only components are the **Router** and the **New Session Queue**. Everything they do, they do with ordinary HTTP requests. ## What the Router is wired to instead `RouterServer` builds three clients from configuration and nothing else: - a `RemoteSessionMap` from `--sessions`, used on every command to translate a session id into a Node URI; - a `RemoteNewSessionQueue` from `--sessionqueue`, where new session requests are parked; - a `RemoteDistributor` from `--distributor`, used by the Grid's own status and GraphQL surface. Note that `SessionMapOptions` defaults its implementation to `RemoteSessionMap`, and throws `Unable to determine host and port for the session map server` if you start `router` without `--sessions`. A `hub` avoids that only because `DefaultHubConfig` overrides the implementation to `LocalSessionMap` and holds the map in its own JVM. ## What the New Session Queue is wired to instead The `sessionqueue` process is the simplest of the six. It takes `--port` and its own timeout settings, and nothing pushes into it or pulls from it over the bus. The Router **posts** a new request to it over HTTP and holds the connection open; the Distributor **polls** it over HTTP through a `RemoteNewSessionQueue` and completes the request when a session exists. Two HTTP peers, no subscriptions. ## Why the distinction matters in practice 1. **It tells you which flags each process needs.** Passing bus addresses to `router` or `sessionqueue` is a sign you have not understood the topology; leaving them off `distributor`, `sessions` or `node` breaks the Grid. 2. **It scopes what a bus outage actually breaks.** The bus carries Node status and heartbeat traffic to the Distributor and session-lifecycle messages to the Session Map. Lose the bus and the Distributor stops hearing about Nodes, and the Session Map stops evicting entries for closed sessions and departed Nodes. 3. **It explains why running commands keep working.** For a car-rental pickup-form session that is already open, the whole path — client to Router, Router to Session Map, Router to Node — is HTTP. Filling in the pickup date and clicking search keeps working while the bus is down; it is *new* sessions and *changed* Node membership that stall. 4. **It shapes what you protect.** The Router is the only component a client ever addresses, so it is the one that carries `--username`/`--password` basic auth and `--sub-path`. The bus ports are internal and should never be reachable from where your tests run. ## Wiring the two HTTP-only roles - Start `sessionqueue` with just `--port 5559`. - Start `router` with `--sessions`, `--distributor`, `--sessionqueue` and `--port 4444`. - Give both the same `--registration-secret` as the rest of the Grid if you have set one, since that secret guards the component-to-component HTTP calls, not the bus. - Do **not** give either of them `--publish-events`, `--subscribe-events` or `--bind-bus`. - Expect `router` to be the only one of the six a client ever connects to, and keep the other five off any network your test machines can reach. A useful sanity check when a distributed Grid misbehaves is to count bus flags: exactly four processes should carry an address pair, and seeing one on the router or the queue means somebody copied a command line without reading it. ## The answer in one breath Six components, four bus members. The Router and the New Session Queue are pure HTTP: the Router because it is a forwarding front door that only ever needs a URL, and the queue because it is a passive store that the Router writes to and the Distributor reads from. Being able to say which two, and why each of them has no reason to subscribe to anything, is what separates a candidate who has run a distributed Grid from one who has read the diagram.

If the Router is not on the bus, how does it find a running session?
It asks the Session Map over HTTP. The router process defaults its session map implementation to the remote one and builds it from the `--sessions` URL, so every command for an open car-rental pickup-form session costs one lookup against the map process and then a direct forward to that Node's HTTP endpoint.
What breaks first if the event bus process dies?
Bus traffic stops, so the Distributor stops receiving Node status messages and the Session Map stops evicting entries for closed sessions and departed Nodes. Commands for sessions already running are unaffected, because the whole path from client to Router to Session Map to Node is HTTP.
Why does the router process fail to start without --sessions?
Its session map implementation defaults to the remote one, which needs a host and a port. Without them configuration resolution throws, complaining it cannot determine the session map server address. A hub avoids this only because its own defaults substitute an in-memory local map instead.

saying these in an interview costs you the question

Says every Grid component connects to the event bus
Thinks the Router subscribes to session events over the bus
Assumes the router accepts the same bus flags as the distributor
Believes the queue subscribes for node availability events
Expects running sessions to fail the instant the bus stops

Which Selenium Grid 4 components talk only over HTTP and never join the event bus?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Who is on the bus and who is not

What the Router is wired to instead

What the New Session Queue is wired to instead

Why the distinction matters in practice

Wiring the two HTTP-only roles

The answer in one breath

▾common follow-ups3 questions

▾red flags5 flags

Who is on the bus and who is not

What the Router is wired to instead

What the New Session Queue is wired to instead

Why the distinction matters in practice

Wiring the two HTTP-only roles

The answer in one breath

answer

go deeper