openConnection

What this module is responsible for

The dev/publisher module is responsible for simulating event streams and task queues to test the Booblik broker. Within this module, the openConnection mechanism ensures that the publisher can gracefully handle the lifecycle of the broker, specifically managing the transition from a container starting up to a state where the network socket is actually accepting connections.

Diagram

The openConnection retry loop

The openConnection function implements a blocking retry mechanism to establish a BooblikConnection. It first resolves the broker's location into an InetSocketAddress using the host and port provided in the PublisherConfig (Main.kt:77). If the connection attempt fails, the function catches the exception, prints a retry message including the failure reason, and waits for 1000 milliseconds before attempting to connect again (Main.kt:82-83).

Broker availability and startup race conditions

The retry loop is a defensive measure against startup race conditions in containerized environments. While docker-compose.yml:44-46 uses condition: service_healthy to ensure the publisher only starts after the broker's health check passes, the code includes the loop because "should never" and "does not" are different claims (Main.kt:72-74). This prevents the publisher from crashing if the broker's process is running but the network stack is not yet ready to accept connections.

BooblikConnection instantiation

Once a connection is successfully established, openConnection returns a new BooblikConnection instance (Main.kt:80). Crucially, this connection is initialized with its own CoroutineScope configured with a SupervisorJob (Main.kt:80). This ensures that failures in child coroutines within the connection do not automatically cancel the entire scope, allowing for more robust error handling during the publisher's execution.

Key files

Behaviour that surprises

• Scope Isolation: The BooblikConnection created in openConnection is given a new CoroutineScope with a SupervisorJob rather than using the caller's scope, which prevents a connection failure from propagating up and killing the entire publisher application (Main.kt:80).
• The "Should Never" Clause: Despite the orchestration provided by Docker Compose, the openConnection function explicitly includes a while(true) loop to handle the edge case where a broker is "not answering yet" (Main.kt:78-82).