When a developer uses service broker to attach a multi-node RMQ cluster to his application, cfenv will only parse the 1st node and ignore the others.
Here is an example of what the ENV variables looks like for a multi-node RMQ cluster.
"p.rabbitmq": [{
xxx
"credentials": {
xxx
"hostname": "q-i0.rabbitmq-server.bosh.rabbitmq.bosh",
"hostnames": [
"q-i0.rabbitmq-server.bosh.rabbitmq.bosh",
"q-i1.rabbitmq-server.bosh.rabbitmq.bosh",
"q-i2.rabbitmq-server.bosh.rabbitmq.bosh" ], }
}]
Note that both hostname and hostnames are listed and hostnames contains the hostname for all 3 nodes.
The top level properties uri, uris, vhost, username, password, hostname, and hostnames provide access to the AMQP 0.9.1 protocol.
However, AmqpCfEnvProcessor calls cfCredentials.getHost() which only parse host and hostname from ENV.
This leads to application totally ignoring the other nodes in RMQ cluster.
An example of ENV parsed by AmqpCfEnvProcessor can be found below.
"name": "AmqpCfEnvProcessor",
"properties": {
"spring.rabbitmq.host": { "value": "q-i0.rabbitmq-server.bosh.rabbitmq.bosh" },
"spring.rabbitmq.password": { "value": "******" },
"spring.rabbitmq.username": { "value": "GUID" },
"spring.rabbitmq.ssl.enabled": { "value": "true" },
"spring.rabbitmq.port": { "value": "5671" },
"spring.rabbitmq.virtualHost": { "value": "GUID" } }
As you can see, there is only 1 host and the other 2 nodes are being ignored.
In this case, if the 1st node is failing, no failover will happen and application will fail.
There is currently no fix for this issue, the GitHub issue can be found here: https://github.com/pivotal-cf/java-cfenv/issues/167
If the application is a Spring Boot Application, then customer can use Java Buildpack Auto Reconfiguration Instead of cfenv as a workaround.
Add JBP_CONFIG_SPRING_AUTO_RECONFIGURATION {enabled: true} to the ENV variables of the application.