Description
Describe the bug
From this conversation: spring-projects/spring-amqp#2522
When RabbitMQ is running in a environment where rabbit node name is not resolvable by the clients, and the client connects locally via the loopback, the client library fails to create a producer and retries infinitely.
This kind of setups are common for local development environments, where rabbit may resolve its node name as foobar
, and the client connects via localhost
. One example is running rabbit locally, and another, running rabbit in a container.
Reproduction steps
- Start RabbitMQ in a container, with a specific hostname
docker run --hostname foobar --rm --name bunny -p 5672:5672 -p 15672:15672 -p 5552:5552 rabbitmq:3-management docker exec bunny rabbitmq-plugins enable rabbitmq_stream_management
- Create a
StreamSystem
that connects tolocalhost
and default port5552
- Create a stream
- Create a producer using
Producer.Create()
Observe that the client does not create the producer connection, and it retries infinitely.
Expected behavior
The client library connects via localhost, or gives up connecting.
Additional context
Related rabbitmq/rabbitmq-server#9424
The issue can be workarounded using an address resolver, or changing the advertised host/port to always be localhost
and the default stream port. However, there's a fair point made in the Spring Boot discussion: spring-projects/spring-amqp#2522 (comment). In summary, if there's no load balancer involved (address resolved was created for LB setups), and there's no rabbit cluster, then the localhost
and default loopback user configuration should work.
This may arguably be an improvement, rather than a bug.