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.
Related
While doing some load tests with the ActiveMQ Artemis broker and my Spring Boot application I am getting into performance issues.
What I am doing is, sending e.g. 12,000 messages per second to the broker with JMSeter and the application receives them and saves them to a DB. That works fine. But when I extend my application by a filter mechanism, which forwards events after saving to DB, back to the broker using jmsTemplate.send(destination, messageCreator) it goes very slow.
I first used ActiveMQ 5.x and there this mechanism works fine. There you could configure the ActiveMQConnectionFactory with setAsyncSend(true) to tune performance. For the ActiveMQ Artemis ConnectionFactory implementation there is no such a possibility. Is there another way to tune performance like in ActiveMQ 5.x?
I am using Apache ActiveMQ Artemis 2.16.0 (but also tried 2.15.0), artemis-jms-client 2.6.4, and Spring Boot 1.5.16.RELEASE.
The first thing to note is that you need to be very careful when using Spring's JmsTemplate to send messages as it employs a well-known anti-pattern that can really kill performance. It will actually create a new JMS connection, session, and producer for every message it sends. I recommend you use a connection pool like this one which is based on the ActiveMQ 5.x connection pool implementation but now supports JMS 2. For additional details about the danger of using JmsTemplate see the ActiveMQ documentation. This is also discussed in an article from Pivotal (i.e. the "owners" of Spring).
The second point here is that you can tune if persistent JMS messages are sent synchronously or not using the blockOnDurableSend URL property, e.g.:
tcp://localhost:61616?blockOnDurableSend=false
This will ensure that persistent JMS messages are sent asynchronously. This is discussed further in the ActiveMQ Artemis documentation.
I need to set consumer priority in a Java app consuming from an AMQP broker.
I want to use Spring JMS to set the consumer priority.
Broker-side, this seems simple; most popular brokers allow setting consumer priority (ActiveMQ, Qpid, RabbitMQ)
Consumer-side, Spring JMS only seems to provide for message priority via setPriority().
Both Spring JMS and Spring AMQP have a class SimpleMessageListenerContainer, but only Spring AMQP's implementation to allows for consumer priority via setConsumerArguments.
I'd be somewhat surprised if Spring JMS didn't provide for consumer priority, but I haven't found any evidence to the contrary.
In Qpid and RabbitMQ we are talking about an AMQP protocol. The ActiveMQ priority sounds like a feature specific to this JMS vendor. There is no standard JMS specification for the consumer priority. That's why Spring JMS doesn't provide any consumer-based priority option.
I am new to jms,
I have did poc of spring jms with ActiveMq. In which I am producing messages in queue and consume it using consumer and one poc in which I am using spring jms with rabbitmq with producer and consumer and have added plugin of jms in rabbit mq to use spring jms with rabbitmq.
Is it Possible if I put Produce message in active MQ and Consume that messages using spring jms rabbitmq consumer?
Is It possible if yes then How?
Thanks in advance.
ActiveMQ and RabbitMQ are two different brokers - why do you need (and why do you think it's possible) to send messages to one broker and receive them from another?
You would need another application to move the messages; it's not clear why you would want to do that.
Typically, you would need an adapter layer to move the JMS messages from one MQ to another (i.e., active MQ to Rabbitmq etc.).
You can look here for some notes (IBM specific) on JMS adapters, but the underlying concept is the same i.e., consuming from one MQ and producing the messages to another MQ.
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"/>
An exclusive consumer in Activemq is one that is sent every message from a broker until the consumer dies or goes away, at which time the broker switches consumer.
What is it that defines when the switchover takes place? How do you configure this in Spring JMS/ActiveMQ?
It's not Spring JMS doing the checking; it's the JMS provider, ActiveMQ.
JMS is an API specification; an empty framework, essentially. ActiveMQ provides the implementation backing for managing connections, message brokering, load-balancing, fail-over, etc.
The ActiveMQ broker handles switching-over consumers based on queue properties (you don't need to do anything special in your code):
queue = new ActiveMQQueue("TEST.QUEUE?consumer.exclusive=true");
The switch-over takes place when either the consumer disconnects gracefully or the broker determines that the consumer has disappeared (via the wireFormat.maxInactivityDuration elapsing without any messages or keep-alives being received). You don't have to configure anything if you're happy with the default value of wireFormat.maxInactivityDuration (30 seconds), but you can tweak that if you want to change how long it takes before the broker gives up on a client.