In Selenium, how does each parallel worker's driver process avoid binding the same port?

## The port a driver process listens on Every browser driver - `chromedriver`, `geckodriver`, `msedgedriver` - is a **local HTTP server**, and Selenium's client speaks the W3C WebDriver protocol to it over a TCP port. Two driver processes bound to the same port is a plain `bind()` failure, and in a parallel run that means one worker alive and the rest dead before a single page loads. ## Selenium's default already avoids the collision - `new ChromeDriver()` calls `ChromeDriverService.createDefaultService()`, which builds a service through `ChromeDriverService.Builder`. - The builder's port field starts at **0**, and `DriverService.Builder.build()` reads 0 as "choose one for me": it calls `PortProber.findFreePort()` before the driver process is launched. - `PortProber.findFreePort()` picks a random port **outside the operating system's ephemeral range** - deliberately, so the choice does not race the OS's own allocations - skips a list of ports browsers refuse to connect to, and proves the candidate free by binding a `ServerSocket` on both `localhost` and `0.0.0.0`. It retries up to ten times, then throws `Unable to find a free port`. - `build()` afterwards resets the builder's port back to 0, so **reusing one builder across workers keeps allocating fresh ports** instead of repeating the first one. So the out-of-the-box shape, where each worker of a museum exhibit catalogue suite constructs its own driver, is port-safe with no configuration at all. ```java new ChromeDriverService.Builder().build(); // free port, safe in parallel new ChromeDriverService.Builder().usingPort(9515).build(); // pinned, collides at N > 1 ``` ## What actually makes it collide 1. **Pinning the driver port.** `usingPort(9515)` on every worker is the classic cause: the number is copied from a debugging session, works serially, and breaks the moment two workers build a service at once. `usingAnyFreePort()` puts a builder back to 0. 2. **Pinning a browser-side port** through the browser's own launch arguments does the same at a different layer, because the browser binary binds it, not the driver. 3. **Pinning geckodriver's BiDi websocket port.** `GeckoDriverService.Builder.withWebSocketPort(n)` fixes that port; leaving it unset makes Selenium pass `--websocket-port 0`, which auto-allocates. ## Sharing one service is not the same as colliding | Setup | Driver processes | Port outcome | |---|---|---| | Each worker builds its own service, port unset | one per worker | a distinct free port each | | Each worker builds its own service with `usingPort(9515)` | one per worker | all fight over 9515 | | Every worker shares one `ChromeDriverService` | one, many sessions | one port, no conflict | | Workers use `RemoteWebDriver` against a grid URL | none locally | one remote endpoint | A **single shared driver service** is a legitimate configuration rather than a bug: one `chromedriver` process can host many sessions, so N workers on one service means one port and no collision. You trade isolation of the driver process for a much lower process count. What is never legitimate is N services each told to use the same fixed number. ## Recognising a port collision from the outside - The failure lands at **driver start**, before any navigation, and the first worker in usually survives. That asymmetry is the tell. - The driver's own log ends with an address-already-in-use bind error, while the Selenium side reports only that the session was never created. - The failure count tracks the worker count exactly: two workers, one failure; six workers, five. - It reproduces on a laptop with the same configuration, which separates it from causes that only appear on a CI agent. To confirm it in one pass: 1. Run the suite with a single worker - a pinned port cannot collide with itself, so it goes green. 2. Grep the configuration for a literal port number reaching a `DriverService.Builder`. 3. Delete the pin, or replace it with `usingAnyFreePort()`, and re-run at the original worker count. ## Where the port sits among the other per-worker resources Getting the port right does not make a worker independent. It still needs its own driver session, its own profile directory and its own download directory, and the host still imposes a memory ceiling on how many browsers can run at once. The port is the cheapest of those to get right, because Selenium gets it right for you unless you deliberately take the choice away.