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.
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.
We have configured our ActiveMQ message broker as a Spring Boot project and there's another Spring Boot application (let's call it service-A) that has a listener configured to listen to some topics using #JmsListener annotation. It's a Spring Cloud microservice appilcation.
The problem:
It is possible that service-A can have multiple instances running.
If we have 2 instances running, then any message coming on topic gets listened to twice.
How can we avoid every instance listening to the topic?
We want to make sure that the topic is listened to only once no matte the number of service-A instances.
Is it possible to run the microservice in a cluster mode or something similar? I also checked out ActiveMQ virtual destinations but not too sure if that's the solution to the problem.
We have also thought of an approach where we can decide who's the leader node from the multiple instances, but that's the last resort and we are looking for a cleaner approach.
Any useful pointers, references are welcome.
What you really want is a shared topic subscription which was added in JMS 2. Unfortunately ActiveMQ 5.x doesn't support JMS 2. However, ActiveMQ Artemis does.
ActiveMQ Artemis is the next generation broker from ActiveMQ. It supports most of the same features as ActiveMQ 5.x (including full support for OpenWire clients) as well as many other features that 5.x doesn't support (e.g. JMS 2, shared-nothing high-availability using replication, last-value queues, ring queues, metrics plugins for integration with tools like Prometheus, duplicate message detection, etc.). Furthermore, ActiveMQ Artemis is built on a high-performance, non-blocking core which means scalability is much better as well.
So using JMS and ActiveMQ, I can be sure that my message sent from my Spring Boot application using JmsTemplate will reach it's destination application even if that destination application is down at the time I send the message to ActiveMQ. As when the destination application starts up, it grabs the message from the queue. Great!
However.
What happens if my Spring Boot application tries to send a JMS message to a queue on the ActiveMQ server, but the ActiveMQ server is down at that point or the network is down and I get a connection refused exception?
What is the recommended way to make sure my application keeps trying to re-sends the message to ActiveMQ until it is successful? Is this something I have to develop into my application myself? Are there any nifty Spring tools or annotations which do this for me? Any advice on best practice or how I should be handling this scenario?
You can try Spring-Retry. Has lots of fine grain controls for it:
http://www.baeldung.com/spring-retry
https://github.com/spring-projects/spring-retry
If it is critical that you don't lose this message, you will want to save it to some alternative persistent store (e.g. filesystem, local mq server) along with whatever retry code you come up with. But for those occasional network glitches or a very temporary mq shutdown/restart, Spring-Retry alone should do the trick.
Couple of approaches I can think of
1. You can set up another ActiveMq as fallback. In your code you don't have to do anything, just change your broker url from
activemq.broker.url=tcp://amq01.blah.blah.com:61616
to
activemq.broker.url=failover:(tcp://amq01.blah.blah.com:61616,tcp://amq02.blah.blah.com:61616)?randomize=false
The rest is automatically taken care of. i.e. when one of them is down, the messages are sent to other.
Another approach is to send to a internal queue (like seda, direct) when activemq is down and read from there.
Adding failover to the url is one appropriate way.
And another reasonable way is to making sure activemq always online , as activemq has the master-slave mode(http://activemq.apache.org/masterslave.html) to get high availability.
I am trying to understand JMS.
What is the difference between ActiveMQ and JMS
can pool the data from NON ActiveMQ with ActiveMQ plugin in Spring?
Thanks ,In advance
JMS is a specification. JMS has three main parts to it. The first is the producer, which is nothing more than a bean that submits a "message" to a JMS broker (#2) (the system that manages messages between producers and consumers). In this case, ActiveMQ is the broker. Once the broker receives a message, the consumer (#3), or Message-Driven Bean (MDB), processes the message.
If you want to work with JMS, you'll just write both your producer/consumer code using the JMS API, but behind the scenes there is a "resource adapter" that is a special ActiveMQ driver that will connect to an ActiveMQ instance and do the management for you.
Have a look at this post I made recently. I'm still trying to figure out the best way to write JMS beans, but I've got the basics down.
The accepted answer emphasizes what is the structure of JMS is. Not disagreeing just want to add to it in case anyone else wants to know. ActiveMQ could be a JMS supplier. A JMS supplier shapes the computer program system for encouraging the utilize of JMS concepts interior an application. A single node of ActiveMQ which permits clients to associate to it and utilize these informing concepts is called an "ActiveMQ Broker."
Enterprises feel this disparity with business actions such as mergers and acquisitions. This creates the need to maintain an increasingly heterogeneous collection of business applications. As your enterprise grows, so does the need to allow all of these platforms to share data. A number of architectural patterns exist today which help to solve this problem.
Some other examples of JMS providers are:
HornetQ.
RabbitMQ.
SonicMQ.
Winsows Azure Messaging
The following example shows a simple configuration of an ActiveMQ connection:
<jms:config name="JMS_Config">
<jms:active-mq-connection >
<jms:factory-configuration brokerUrl="tcp://localhost:61616" />
</jms:active-mq-connection>
</jms:config>
This post explains a detailed difference between the ActiveMQ and JMS (or maybe about the details of their specifications). Hope it clears your concepts.
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