I set up ActiveMQ Artemis consumer using spring-boot-starter-artemis and JMS. I also launched broker locally and I aim to configure these to communicate over OpenWire protocol. To constrain communication to that protocol I modified acceptor in broker.xml (protocols=OPENWIRE). It looks like that:
<acceptor name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true;supportAdvisory=false;suppressInternalManagementObjects=false</acceptor>
However, unfortunately I'm getting the following error:
org.springframework.jms.UncategorizedJmsException: Uncategorized exception occurred during JMS processing; nested exception is javax.jms.JMSException: Failed to create session factory; nested exception is ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ219013: Timed out waiting to receive cluster topology. Group:null]
How can I configure the client to use OpenWire protocol?
What is the default protocol they communicate on? Before I constrained the communication, Artemis Console was presenting the connection has been established on CORE protocol, which as far as I understand collective protocol. Which one i target protocol they really communicate on and how can I check this out?
The reason you're receiving ActiveMQConnectionTimedOutException is because you trying to use spring-boot-starter-artemis to connect to an acceptor which is configured to only support the OpenWire protocol. This will never work because spring-boot-starter-artemis depends on artemis-jms-client which will only use the ActiveMQ Artemis "core" protocol, not OpenWire.
You should configure the acceptor in broker.xml to support core, e.g.:
protocols=CORE,OPENWIRE
If you want the client to use OpenWire then you need to use the OpenWire JMS client library from ActiveMQ "Classic."
Related
I've encounter a problem where our WebSocket connections to ActiveMQ 5.13.3 are terminated abruptly. I thought, I might use WireShark to inspect the TCP layer for clues why the connection may be corrupted, but I'm not sure the ActiveMQ uses TCP protocol as its transport layer protocol for sending the messages.
All the kinds of clients and protocols which ActiveMQ supports use TCP as their transport layer. WebSockets specifically use TCP.
ActiveMQ Broker supports many transport layer protocols, including TCP.
References:
If you are using ActiveMQ Classic:
https://activemq.apache.org/components/classic/
If you are using ActiveMQ Artemis:
https://activemq.apache.org/components/artemis/
I was following the https://docs.spring.io/spring-boot/docs/2.0.0.M3/reference/html/boot-features-messaging.html#boot-features-artemis guide.
With Core protocol with JMS, app is able to send message to Artemis broker.
spring.artemis.mode=native
spring.artemis.host=<broker host>
spring.artemis.port=61616
spring.artemis.user=admin
spring.artemis.password=<password>
When I switched to AMQP protocol with 5672 port, I am getting below error.
spring.artemis.mode=native
spring.artemis.host=<broker host>
spring.artemis.port=5672
spring.artemis.user=admin
spring.artemis.password=<password>
Caused by: org.apache.activemq.artemis.api.core.ActiveMQConnectionTimedOutException: AMQ219013: Timed out waiting to receive cluster topology. Group:null
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:712) ~[artemis-core-client-2.12.0.jar:2.12.0]
at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:884) ~[artemis-jms-client-2.12.0.jar:2.12.0]
... 68 common frames omitted
what changes I have to make along to enable transition over AMQP protocol in my spring boot app? Thanks.
In order to use the AMQP protocol you'd need to somehow force Spring to use the Qpid JMS client implementation rather than ActiveMQ Artemis' core JMS client implementation, but I don't believe that is possible.
I have a Spring Boot application using Qpid JMS to speak AMQP with an ActiveMQ 5.15.14 broker. Even though the redelivery plugin is configured, the redelivery policies of the broker are ignored. However the redelivery policy of the client (Qpid) does come into play.
When the exact same code and client configuration is connected to a ActiveMQ Artemis broker, the redelivery policy of the broker kicks in which is what I'm looking for.
Anything you are aware of that could explain this different behavior between ActiveMQ 5 and ActiveMQ Artemis? Both brokers are using pretty much OOTB configuration aside from the redelivery policies, and schedulerSupport is enabled in my ActiveMQ 5 broker as well. Here's what the redelivey configuration looks like in activemq.xml:
<redeliveryPlugin fallbackToDeadLetter="true" sendToDlqIfMaxRetriesExceeded="true">
<redeliveryPolicyMap>
<redeliveryPolicyMap>
<defaultEntry>
<redeliveryPolicy initialRedeliveryDelay="5000" maximumRedeliveries="9" redeliveryDelay="60000" />
</defaultEntry>
</redeliveryPolicyMap>
</redeliveryPolicyMap>
</redeliveryPlugin>
One more thing to consider : the redelivery policies of the ActiveMQ 5 broker are applied when I use Openwire (JMS) instead of AMQP.
The AMQP protocol head in ActiveMQ 5.x is far more primitive than that of the Artemis broker implementation and is likely not reacting correct to the dispositions that are being sent back from the AMQP client. Also the 5.x broker can react differently based on the transformer setting in the 'transportConnector' on the broker which can be one of JMS, NATIVE or RAW. The JMS transformer will give the most ActiveMQ compatible behaviour but requires a complete transformation internally to an OpenWire message and then back to AMQP when going from AMQP sender to AMQP receiver which can hurt performance significantly. The NATIVE transformation will attempt to preserve some insights into the redelivered state of the message but won't catch every case most likely. With the RAW mode there will be no insight into the message delivery count at all and as such you definitely won't get any redelivery processing on the broker side.
I short, if you are looking for a fully functional AMQP broker then choose Artemis as it has had a lot of work, if you just need something that can get messages flowing then 5.x should work but don't expect the same quality of service.
I have an activeMQ broker that supports both amqp and openwire.
Is it possible that a producer of openwire (tcp, port 61616) will produce to a queue that have a consumer that uses amqp protocol instead?
or am i limited to the same protocol consumers&producers only?
Yes, it is possible to interoperate with the OpenWire JMS client and an AMQP client using ActiveMQ. The destinations that hold the messages are not separate spaces therefore message place on a Queue by a client of one type are consumable by a client from some other protocol.
The only thing that you have to contend with is how the actual messages are conveyed to each client. ActiveMQ provides a configurable transfomer that can either preserve the original bytes of the AMQP message when sent from an AMQP client or transform that message into a more JMS style message object that would be received by the OpenWire client as the expected type (TextMessage, BytesMessage, MapMessage...).
Refer to the documentation of ActiveMQ for help in configuration and in understanding the mappings of AMQP to OpenWire messages.
http://activemq.apache.org/amqp.html
If you want to easiest to handle scenario where messages are transformed and always arrive at the OpenWire client as proper JMS types choose the JMS Transformer in configuration like so:
<transportConnector name="amqp" uri="amqp://localhost:5672?transport.transformer=jms"/>
We are using IBM MQ as MoM for Java based JMS application. I need to know the underlying communication protocol used by ibm mq. Specifically, if I need to communicate using MQTT protocol with IBM MQ, do I need to use MQ Telemetry product ?
The MQ JMS client will use a proprietary protocol to communicate to the queue manager rather than the MQTT protocol. This proprietary protocol is not published externally like the MQTT protocol is.
If you need to use the MQTT protocol then you will need to use a MQTT client.