I ran into an issue yesterday and I’m not sure how much of a Docker or Compose issue it is, or if it was just me that shot myself in the foot.
My RabbitMQ container name had underscore in it and the Java application trying to connect to it was setting up the connection factory by passing it a java.net.URI object create roughly like so:
new URI("amqp://guest:guest@"+another's container name via environment variable+":5672").
Deep down, java.net.URI parses the received String (something like “amqp://guest:guest@be_rabbitmq:5672”) and fails on the hostname part. This left the “host” field of the java.net.URI object null.
I have found an interesting answer on whether hostname and domain name can have underscore in them:
For some reason, it never occurred to me that underscore could be dangerous in a hostnames. Now that I think of it, I don’t remember seeing it anywhere.
Anyway, what is Docker or Compose stance on this? Are underscore allowed in container–>dns names?
In much more details, here’s what happened:
I had to manage a set of services in Docker. They all have to be part of the same docker-compose.yml, but there’s two logical groups: backend and frontend. Because some components already had hyphens in their name, I decided to name the containers with the following convention: prefix_project-name. E.g.: be_redis, be_rabbitmq, fe_the-service, fe_the-app.
This worked great for all of the backend stack (RabbitMQ, elasticsearch, Redis, DynamoDB local, etc) and most of the front-end stack (Node.js apps, Nginx router).
However, when I added to the lot a Java application that needed to connect to Reddis, it wouldn’t work.
I pinpointed the problem to that line:
CachingConnectionFactory connectionFactory = new CachingConnectionFactory(new URI(rabbitMQUrl));
rabbitMQUrl value was: amqp://guest:guest@be_rabbitMQ:5672
When logging the state of the connection factory, it said that the host was localhost:
log.debug("DEBUG--- connectionFactory: "+connectionFactory); //output: DEBUG--- connectionFactory: CachingConnectionFactory [channelCacheSize=1, host=localhost, port=5672, active=true ...]
So I edited the code to explicitly set the host and logged again:
connectionFactory.setHost("be_rabbitMQ"); log.debug("DEBUG--- connectionFactory: "+connectionFactory); //output: DEBUG--- connectionFactory: CachingConnectionFactory [channelCacheSize=1, host=be_rabbitMQ, port=5672, active=true ...]
That was very intriguing and by digging deeper, as said at the beginning of this thread, I found that java.net.URI parses the received String and fails on the hostname part. This left the “host” field of the java.net.URI object null. The Java RabbitMQ ConnectionFactory protects itself against null hostname and falls back to localhost, should uri.getHost() == null.