In Selenium 4, what does Grid's standalone command run inside its single process?
answer
- Count how many processes you actually start
- Everything, and nothing over a socket
- In-memory implementations of every component
- One router, mounted at two paths
- Guava event bus, local session map
basics
~20 sAll of it. Selenium 4's standalone command builds the router, distributor, session map, new session queue, event bus and node in one JVM, serving WebDriver on port 4444 at both the root path and /wd/hub.
solid answer
~40 s`standalone` is a Selenium 4 server command that declares every Grid role and then builds them all inside one JVM. It picks the in-memory implementations — a `LocalSessionMap`, a `LocalNewSessionQueue`, a `LocalDistributor` and a `GuavaEventBus` — so no component needs a socket to reach another, and no event-bus ports are opened at all. The internal HTTP client is a `RoutableHttpClientFactory`, which short-circuits any call addressed to the server's own URI into an in-process `CombinedHandler` instead of loopback traffic. The public surface is one router mounted twice: `/` and the legacy `/wd/hub` prefix reach the same WebDriver routes, alongside a GraphQL route, the console and a `/readyz` readiness endpoint. The 4444 default comes from the standalone command's own flags.
code
bash · 3 linesjava -jar selenium-server.jar standalone --port 4444 &
until curl -sfo /dev/null http://localhost:4444/readyz; do sleep 1; done
echo "Timetable board grid ready at http://localhost:4444"go deeper
Know that one command starts the whole Grid and that tests talk to it on port 4444. Naming the standalone role and its default port is enough for a screening answer at this level.
Explain the assembly itself: every component built in memory inside one JVM, an event bus that never touches the network, and one router mounted at both the root and /wd/hub. This is the tier where those mechanics are expected.
Reason from that design to its consequences in production: no state across a restart, one log to read, and a process failure taking every session with it. Say what you would probe to prove the server is actually serving.
Frame in-process assembly as a deliberate coupling trade. It removes a whole class of network and registration failure in exchange for a hard single-host ceiling, and you should be able to say when that trade stops paying for an organisation.
## The one-command claim, precisely In **Selenium 4**, `standalone` is a subcommand of the Selenium server jar, described in its own source as the Selenium server running everything in-process. Starting it produces one JVM that declares every configurable Grid role at once and then builds each one as an ordinary Java object on that process's heap: - **router** — the HTTP entry point the client actually talks to, - **distributor** — the part that places a request on a slot, - **session map** — the id-to-session lookup, - **new session queue** — where a request waits, - **event bus** — how the parts notify each other, - **node** — the thing that owns browsers on this host. There is no supervisor, no second JVM and no local orchestration. For a team testing a **train timetable board**, the practical translation is that one command yields a real remote WebDriver endpoint on `http://localhost:4444`, and nothing else has to be started, registered or reachable. ## Which implementations it picks Standalone does not merely start those parts; it deliberately selects their **in-memory** implementations, some pinned by the command's own default configuration and the rest constructed locally in the code that assembles the handlers. | Component | Implementation standalone uses | Where the state lives | |---|---|---| | Session map | `LocalSessionMap` | the process heap | | New session queue | `LocalNewSessionQueue` | the process heap | | Distributor | `LocalDistributor` | the process heap | | Event bus | `GuavaEventBus` | in-JVM dispatch, no socket | The consequence is the single most useful fact about this mode: **standalone opens no event-bus sockets at all.** A deployment that splits roles across machines needs a networked bus so that separate processes can hear one another. Standalone has one process, so an event is a method call and never leaves the heap. `GuavaEventBus` is a thin wrapper over Guava's `EventBus`, and its readiness check simply returns true — there is nothing to connect to. ## Why internal calls never touch the network Grid components talk to each other through an HTTP client abstraction, which would normally mean loopback requests even on a single host. Standalone avoids that with `RoutableHttpClientFactory`. When a component asks for a client whose base URI has the same scheme, host and port as the server's own external URI, the factory returns a client that opens no socket: it tests the request against a `CombinedHandler` and, if a handler matches, executes it directly. A request that matches nothing comes back as a `404` naming `UnsupportedCommandException` rather than travelling anywhere. The boundary is therefore sharp: **the client's traffic is real HTTP; the grid's internal traffic is method dispatch.** ## The HTTP surface on port 4444 The listener is assembled from a small set of routes: - The **root path**, serving the WebDriver routes through the router with spec-compliance checks applied. - The **`/wd/hub` prefix**, mounted onto exactly the same router. It is a Selenium 3-era shape kept alive so that older client configuration still resolves; in Selenium 4 it is an alias, not the canonical address. - A **GraphQL route**, and the Grid console unless the UI has been disabled. - **`/readyz`**, combined in after any basic-authentication filter so a readiness probe can always reach it. It answers `200` with the text `Standalone is true` once the session map, the distributor and the bus all report ready, and `503` otherwise. The port is worth tracing too. The generic server layer, given no configured port, would pick any free one; the `standalone` command supplies its own flag default of **4444**, which is why the number appears with no configuration at all. `-p` or `--port` overrides it. ## What the design costs 1. **No durability.** Every piece of state is on the heap, so a restart loses running sessions and anything waiting. 2. **One failure domain.** A crash takes the router, the queue and the node together, because they were never separable. 3. **One machine's ceiling.** Concurrency is bounded by what this host can run, and the only way past it is a different topology. For a long-lived shared service those would be real objections. For a CI job they are close to ideal: a server whose state dies with the build cannot leak into the next one.
- Why does a standalone server not open the event-bus ports that a multi-process deployment needs?Because its bus is `GuavaEventBus`, an in-JVM bus rather than a networked one. Every component that would publish or subscribe lives in the same process, so an event is a method dispatch between objects already sharing a heap. Nothing outside the process has to observe them, so there is nothing to bind.
- If everything is in one process, why is there an HTTP router at all?Because WebDriver is an HTTP protocol and the client is outside the process. The router is the public door: it takes the new-session request, applies spec-compliance checks and proxies the session's later commands. Internally those hops are short-circuited by `RoutableHttpClientFactory`, but the client still speaks plain HTTP to port 4444.
- What happens to a standalone server's state when the process exits?It is gone. The session map, the queue and the bus are in-memory objects owned by that JVM, so a restart loses every running session and everything waiting. That is a feature for a CI job, whose server should die with the build, and a reason not to treat a standalone server as long-lived shared infrastructure.
A large terminus has a separate signaller, dispatcher, announcer and platform staff. A country halt has one person doing every one of those jobs behind a single window, and the timetable board still updates.
saying these in an interview costs you the question
- Thinks standalone starts several JVMs and coordinates them locally
- Says standalone omits the router and talks straight to the node
- Believes standalone's internal Grid calls still travel over loopback HTTP
- Assumes /wd/hub is the only valid endpoint on a Selenium 4 server
- Expects a standalone server to keep its sessions across a restart