skip to content

In Selenium Grid 4, why does the event bus bind two separate ports, 4442 and 4443?

level: middleimportance: nice to knowfreq 31%

answer

  1. The bus is a broker, not a pipe
  2. Two sockets, not one
  3. One direction in, one direction out
  4. The flag names take the bus's view
  5. XPUB on 4442, XSUB on 4443

basics

~20 s

The Grid 4 event bus is a ZeroMQ proxy with two ends. Port 4442 is the socket the bus publishes from and every component subscribes to; port 4443 is the socket the bus subscribes on and every component publishes to.

solid answer

~40 s

The bus is an XPUB/XSUB proxy, so it needs one socket for messages coming in and one for messages going out. `--publish-events` defaults to `tcp://*:4442` and is the address the bus publishes from, so a component connects its `SUB` socket there to receive events. `--subscribe-events` defaults to `tcp://*:4443` and is the address the bus subscribes on, so a component connects its `PUB` socket there to send. The names describe the bus's behaviour, not yours, which is why they read backwards. Every bus member must be given the same pair, and `--bind-bus` decides which single process actually binds them. Port `5557` is unrelated: it is the `event-bus` process's own HTTP port.

code

bash · 8 lines
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 node \
  --publish-events tcp://10.0.0.5:4442 \
  --subscribe-events tcp://10.0.0.5:4443

go deeper

for a junior

Know that the event bus is internal plumbing on ports 4442 and 4443, and that your tests never touch it. Pointing a suite at those ports instead of 4444 is a common first mistake.

for a middle

Explain that the bus is a proxy with an inbound and an outbound socket, and that the flag names describe the bus rather than the component reading them.

for a senior

Demonstrate diagnosis: a swapped or split address pair starts cleanly and delivers nothing, so read the connecting and binding log lines rather than trusting a healthy process.

for a principal

Own the network boundary. Decide who may reach the bus ports at all, and whether the message channel deserves its own host once the Node count grows.

## The event bus is a broker, not a port In Selenium Grid 4 the event bus is a **ZeroMQ XPUB/XSUB proxy** running inside whichever process is told to host it. A proxy of that shape has two ends, and each end is a separate socket on a separate port: one socket that messages come *in* on, and one socket that messages go *out* on. That is why the docs list `4442`, `4443` and `5557` for the `event-bus` process rather than a single port. The `BoundZmqEventBus` class creates an `XPUB` socket, binds it to the publish address, creates an `XSUB` socket, binds it to the subscribe address, and then runs a ZeroMQ proxy between them. Every other component runs an `UnboundZmqEventBus`, which creates a plain `SUB` socket and a plain `PUB` socket and *connects* them to those same two addresses. ## Why the flag names read backwards The two flags are named from the **bus's** point of view, not the component's, and this is the single most common source of confusion on this topic. | Flag | Default | Socket the bus binds | What a component connects there | |---|---|---|---| | `--publish-events` | `tcp://*:4442` | `XPUB` — the bus publishes from here | its `SUB` socket, to *receive* events | | `--subscribe-events` | `tcp://*:4443` | `XSUB` — the bus subscribes here | its `PUB` socket, to *send* events | | `--bind-bus` | `true` on the bus host, `false` elsewhere | decides bound versus connected | nothing; it is a boolean | So a Node that wants to announce itself sends on port **4443**, even though the flag holding that address is called `--subscribe-events`. A Distributor that wants to hear about Nodes listens on port **4442**, even though the flag holding that address is called `--publish-events`. Reading the flag names as instructions to your component is exactly backwards. ## The third port `5557` is not part of the message plumbing at all. It is an ordinary HTTP port served by the `event-bus` process, with two routes: - `GET /status` fires a `healthcheck` event through the bus and waits up to five seconds for it to come back, answering `Event bus running` only if the proxy actually delivered it. That makes it a real end-to-end check, not just a liveness ping. - `GET /readyz` returns an empty `204`. ## Wiring a car-rental pickup-form grid 1. Start the bus, giving both addresses on the interface the other machines can reach: `--publish-events tcp://10.0.0.5:4442 --subscribe-events tcp://10.0.0.5:4443 --port 5557`. 2. Give the **identical pair** to the Distributor, the Session Map and every Node. Not a swapped pair, not a subset. 3. Open both ports on the firewall between every bus member and the bus host. They are TCP, but they are not HTTP, so a proxy that only understands HTTP will not carry them. 4. Confirm from each component's log: a bus member logs `Connecting to` followed by the two addresses, while the host of the bus logs `XPUB binding to ... XSUB binding to ...`. ## Symptoms when the pair is wrong - **Addresses swapped.** Each process starts cleanly and logs a successful connection, because ZeroMQ connect does not fail on an address nobody is listening to. Nothing is ever delivered, so the Distributor sees no Nodes and every car-rental pickup-form request sits in the queue until it is rejected. - **Only one address given.** The component falls back to deriving the pair from its hub address if it has one, and otherwise fails at startup with `Unable to find address to publish events to.` - **Two different bus hosts.** You have two buses. Each half works internally and neither can see the other. - **Port 5557 confused with 4444.** `5557` answers for the bus process; `4444` is the Router's client-facing port. Pointing your suite at `5557` gets you a health endpoint, not a Grid. ## What to say in an interview The short version is: two ports because the bus is a proxy with an inbound socket and an outbound socket, the flag names describe the bus's behaviour rather than yours, and every component must be handed the same pair. If you can add that `4442` is where you *listen* and `4443` is where you *send*, you have said the part most candidates get inverted.

  • What is port 5557 for on the event-bus process?
    It is that process's own HTTP port. `GET /status` fires a healthcheck event through the bus and waits up to five seconds for it to come back, answering `Event bus running` only if the proxy actually delivered it, so it proves message flow rather than mere liveness. `GET /readyz` returns an empty 204.
  • What happens if two components are given different subscribe addresses?
    They end up on different buses. Both start cleanly, because a ZeroMQ connect succeeds against an address nobody is bound to, but nothing crosses between them. A Node publishing its status to one address while the Distributor listens on another simply never appears in the Grid, with no error anywhere.

saying these in an interview costs you the question

  • Says 4442 is where components publish because the flag says publish
  • Thinks the bus speaks HTTP on 4442 and 4443
  • Gives each component a different event bus address pair
  • Assumes one port could carry both directions
  • Confuses port 5557 with the client-facing Grid port