Details
Major Description
I have a network of three brokers on three different hosts each with nio transport connectors as follows (host 1 below, hosts 2 and 3 follow the same pattern):
<transportConnector name="openwire-client"
uri="nio://host1.somedomain.com:44320"
updateClusterClients="true"
rebalanceClusterClients="true"
updateClusterClientsOnRemove="true"
/>
I modified the ActiveMQ C++ example Listener (Listener.cpp) with the following broker URL:
failover:(tcp://host1.somedomain.com:44320)
The Listener hangs in connection->start() and never establishes a connection with any of the three brokers.
I put debug into FailoverTransport.cpp and discovered that the URIs received from the three brokers are being used verbatim by the C++ client - i.e. it tries to rebalance/reconnect using the nio scheme in the URIs received from the broker transport connector configuration.
The C++ client has no handling for the nio scheme and so continually iterates though the URI pool but never establishes a connection to any of the URIs, hence the hang.
According to the ActiveMQ website "Configuring Transports" documentation if the nio transport is specified in a URI used by an OpenWire client, it should simply instantiate the normal tcp transport, but this handling seems to be missing from the C++ client.
I put a quick fix into the FailoverTransport::updateURIs() method to convert any URI received from a broker with a scheme of "nio" to the same URI but with a scheme of "tcp" and then the client successfully connected to one of the brokers:
Pointer<Iterator<URI> > setIter(set.iterator());
while (setIter->hasNext()) {
URI value = setIter->next();
if (value.getScheme() == "nio")
this->impl->updated->addURI(value);
}
This is obviously not an appropriate solution for the production code, but it does serve to demonstrate the issue.