Introduction

java.net.BindException: Address already in use means a Kafka or Confluent component tried to open a host-and-port combination that the operating system has already assigned to another process. The fix is not in Java code; it is in identifying the conflicting process or correcting the service configuration so each component listens on a unique port.

Where This Happens in Kafka Setups

In a Kafka stack, several services bind to network ports:

• broker listeners such as 9092
• Schema Registry, often 8081
• Kafka Connect REST API, often 8083
• Control Center and other local tooling ports

The error appears when one of these ports is already occupied, or when you start a second copy of the same service on the same machine without changing the port.

Find What Is Holding the Port

On macOS or Linux, start by checking the specific port.

lsof -i :9092

Or:

ss -ltnp | grep 9092

If another Kafka broker or unrelated process is already listening there, you have found the conflict. Either stop that process or configure your new service to use a different port.

Fix the Kafka Listener Configuration

For a Kafka broker, the binding port is usually controlled by listeners.

listeners=PLAINTEXT://:9093
advertised.listeners=PLAINTEXT://localhost:9093

If 9092 is already in use, changing both settings to 9093 is a common local-development fix. Remember that listeners controls where the broker binds, while advertised.listeners controls what address clients are told to use.

For other Confluent services, the equivalent setting lives in that service's configuration file.

A Common Local-Development Scenario

A frequent mistake is leaving one old broker running in the background and then starting a new one from a different terminal. The new process fails with BindException, but the real problem is simply that the original broker is still alive.

Another common case is Docker. If a container already publishes 9092:9092, starting another container or local broker on the same host port will fail. In that case, change the host-side mapping or stop the first container.

Example: Connect REST Port Conflict

Kafka Connect has its own REST listener. If that port is taken, the fix is similar:

listeners=http://0.0.0.0:8084

Again, every service on the host must have a unique bound port.

In distributed environments, also distinguish between bind problems and connectivity problems. BindException happens before remote clients are even involved. It means the local machine could not claim the port, so start by fixing the local listener configuration first.

Common Pitfalls

The biggest mistake is changing only advertised.listeners and forgetting listeners. Clients may see the new address, but the broker still tries to bind the old port locally.

Another mistake is assuming the port conflict comes from Kafka when the real owner is an unrelated process. Always inspect the operating system state first.

A third mistake is fixing the port conflict but forgetting to update clients, Docker mappings, firewall rules, or dependent services that still expect the original port.

Summary

• 'BindException means the operating system rejected a port bind because something else is already using it.'
• Check the actual port owner first with tools such as lsof or ss.
• For Kafka brokers, correct both listeners and advertised.listeners when changing ports.
• The same issue applies to other Confluent services such as Schema Registry and Kafka Connect.
• Local background processes and Docker port mappings are two of the most common causes.