Problems using activemq-client jar vs activemq-all jar

Question

I need to use activemq-client rather than the roll-up activemq-all JAR files because the roll-up all contains different versions of other libraries we use.

I'm using maven to manage dependencies, the client jar pulls in:

activemq-client (5.15.8)
slf4j-api 1.7.25
geronimo-jms_1.1_spec (1.1.1)
hawtbuf (1.11)
geronimo-j2ee-management_1.1_spec (1.0.1)

The all jar is just activemq-all (5.15.8)

Using this code, with the activemq-all jar, I can connect and start receiving messages. At the createConnection() call, I get a log message "Successfully connected to ..."

Using the activemq-client jar, it hangs at the createSession() call (and outputs a "failed after 10 attempts, will continue trying" message). I do not get the "Successfully connected to ..." message.

ConnectionFactory factory = new ActiveMQConnectionFactory(user, pass, url);
Connection AMQconn =  factory.createConnection();
Session AMQsess =  AMQconn.createSession(false, Session.AUTO_ACKNOWLEDGE);
Queue queue = AMQsess.createQueue(queueName);
MessageConsumer AMQconsumer = AMQsess.createConsumer(queue);

I assume I'm missing a dependency somewhere, but I'm not getting a no class def found exceptions, etc.

(I also used activemq version 5.15.9, but our server is 5.15.8, so sticking with that).

The bigger picture (why the client jar vs the roll-up jar): I need to connect to a hornetQ and an AMQ in the same process, and breaking out the individual jars is my attempt at fixing conflicting versions of things in the roll-up jars)

Try capturing the logs and posting what it says about the connect attempt otherwise it is quite challenging to guess what is going on — Tim Bish
Great suggestion, tim-bish I feel dumb for not having thought of that. Thank you. activemq-client doesn't like "auto" in the connection string, but does like "tcp". activemq-all can handle "auto". I can't find anything in the documentation about that (other than 5.13 introduced 'auto'). Is this an amq bug, or misconfiguration on my part ? — K5 User

Tim Bish Tim Bish · Accepted Answer · 2019-06-17T19:16:47

The question omits the URI but the comments seem to indicate that the user is try to connect via a URI of the form: auto://localhost:61616. This would be the problem given the Auto transport makes no sense on the client end as it is meant to detect at the broker side automatically what protocol a connecting client is using and switch to that protocol automatically. The Auto transport allows the broker to support multiple protocols on a single open port that clients would connect to.

The ActiveMQ JMS client must always be using the Openwire protocol (that's what it was built to do) and therefore the URI for the client would be of the form tcp://, ssl:// or failover:// etc.

There are some special convenience classes that kick in if you include the ActiveMQ broker jar that will just map URIs that include scheme's that don't make sense in the client like nio, nio+ssl or auto but they are not included in the client only jar as they really don't belong there since they just aren't intended for use on the client side.

Problems using activemq-client jar vs activemq-all jar

1 Answers