I have problems creating a durable subscription to a topic in RabbitMQ using the Qpid JMS client.
I tried the following:
session.createDurableSubscriber( topic, "name" );
but I get a JMSAMQException with the message "Queue bound query failed: Woken up due to class javax.jms.JMSException"
Does anyone know the correct way to set up a durable subscriber using Qpid JMS client connecting to RabbitMQ?
This looks to be a Qpid JMS client bug.
The createDurableSubscriber path is making use of a Qpid specific extension to the AMQP specification which RabbitMQ does not support (specifically exchange.bound). In order for interoperability, it should be guarding such calls in a similar way to QPID-5224.
I'd suggest reporting this on the Qpid users list and raising a JIRA/submitting a patch.
Related
Push-subscription
Is there a way in springboot or quarkus (or other framework) to consume messages from IBMMQ using push-subscription. I.e Not polling every minute to see if message exists.
Need not be JMS api.
The DefaultJms... in springboot is polling 1000x times more than the actual messages per day. It is not behaving as ' listener waiting for message push'
You could consume messages from IBM MQ using vert.x's AMQP client. This is a reactive toolkit that will give you an easy way of communicating with IBM MQ using the AMQP channel. Vert.x's AMQP client listens and reacts for push from IBM MQ.
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 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.
We are using ActiveMQ as our standard messaging platform. XD already supports ActiveMQ as JMS source. Messaging platform as transport helps handle the sink failures by putting the payload in the ERROR queue named after the transport. If it were Redis, the payload goes into a LIST. Queue is better way to process the failed messages using a batch job. Wondering if ActiveMQ will be supported as a transport in future.
I created https://jira.spring.io/browse/XD-1928 and put it on the roadmap for a 1.1 M1 release which will be later in the year. Rabbit as the broker supports the same error handling semantics you mention.
https://github.com/spring-projects/spring-xd/wiki/XD-Distributed-Runtime#error-handling-message-delivery-failures
has more info on error handling for both Redis and Rabbit.
Rabbit is the preferred message bus to use ATM, we also support redis since it is a way to validate the messagebus abstraction and it is already 'there' since we use it to store analytics.
Thanks for the feedback.
Cheers,
Mark
I wonder what is the correct way to subscribe to a Topic using Spring.
I tried with a DefaultMessageListenerContainer, using a non-durable subscription, but it fails most of the time. There is an open bug (SPR-7833) that seems to point out it will not work for non-durable topic subscriptions.
Is there any alternative to the DMLC that supports auto-reconnection in case of failure?
By the way, I'm creating the DMLC programmatically, connecting to an embedded ActiveMQ 5.5.1 broker using the Failover Transport for automatic reconnection. Consuming messages from Queues work as expected even in the most bizarre scenarios, but no luck with Topics.