What is ActiveMQ used for - can we apply messaging concept using a Database? [closed]

Question

I looked it up and it used to send messages between 2 systems. But why? Why wouldn't you just use a database?

There must be some feature that ActiveMQ has that databases do not?

Thromboplastin

Similar question https://mcmap.net/q/189152/-what-is-an-mq-and-why-do-i-want-to-use-it/460775 – Unravel

Answer 1

It is used to reliably communicate between two distributed processes.

Yes, you could store messages in a Database to communicate between two processes, but, as soon as the message is received you'd have to DELETE the message, That means a row INSERT and DELETE for each message.
When you try to scale that up communicating thousands of messages per second, Databases tend to fall over.

Message-oriented middle-ware [MOM] like ActiveMQ on the other hand are built to handle those use cases.
They assume that messages in a healthy system will be deleted very quickly and can do optimizations to avoid the overhead.

It can also push messages to consumers instead of a consumer having to poll for the new message by doing a SQL query.
This further reduces the latency involved in processing new messages being sent into the system.

Rakes

Nice explanation! Does the two distributed processes have to be of the same process? I mean two instances of the same application? – Giffer

No, arbitrary applications can communicate with each other over ActiveMQ. For example, applications A and B could create qeues A.B and B.A (read: messages for A from B and the other way round) and send messages for each other to the matching queue. – Natalya

I have a particular use case where I require to store object state information (such as a car with its GPS, Fuel, and Engine Oil info), so that some other client software can receive this information the moment they connect to the server, even if the info has been pushed hours ago and has not been updated. Like a cache, so that I do not need to query the database several times. Also, when the info does change, it is pushed to the client. For this case, what am I looking for? – Voodooism

Answer 2

ActiveMQ, or in general all Message Oriented Middleware (MOM) implementations are designed for the purpose of sending messages between two applications, or two components inside one application.

Essentially, MOM and databases share a common foundation in that they provide transactional and persistent data storage to can read and write from.
The big difference is the usage pattern - where databases are very generic and optimized for complex searching over multiple tables, MOM is optimized for reading messages, one at a time, in a FIFO like fashion [Queue].

JMS, which is an API ActiveMQ implements, is an important cornerstone in Java Enterprise applications. This makes messages share a rather common format and semantic, which makes integration between different applications easier.

Of course, there are a lot of more detailed features that are only in ActiveMQ, wire protocols like OpenWire, STOMP and MQTT, JMS, EIP together with Apache Camel, message patterns like "request/reply" and "publish/subscribe", JMS Bridging, clustering ("network of brokers"), which allow scaling and distributions, etc.
You should read up on those topics a bit if you are interested since they are rather large.

Weigle

Nice explanation, sir. Any detailed tutorial/web resource on ActiveMQ you can refer to? – Hyperthyroidism

@SaswataMishra this is a 10 year old answer. The world has changed a bit, there might be other better approaches. Anyhow, this tutorial sort of covers all the basics if you're working with java at least. devglan.com/spring-boot/spring-boot-jms-activemq-example – Weigle

Answer 3

ActiveMQ has great scheduler support, which means you can schedule sending your message to be delivered at a particular time.

We have used this feature to send medication reminders to patients uploading their medication details in a health care scenario.

Cherrylchersonese

That's pretty cool. We have used the Quartz scheduling library for similar reminder purposes. – Academy

We have used the Oracle database Scheduled Jobs for the same purposes. – Gause

Answer 4

With RDBMS, when you process a row of data, you typically update a flag indicating that the row has been processed so that the processing is not repeated.

However, with Message Queue, you only have to acknowledge a message and the next consumer will process the next one.

The difference is that the UPDATE statment in a RDBMS is a really slow operation compared to the acknowledge in activmeq.

Unrivalled

Answer 5

From Wikipedia

Apache ActiveMQ is an open source message broker written in Java together with a full Java Message Service (JMS) client. It provides "Enterprise Features" which in this case means fostering the communication from more than one client or server

Regarding your queries:

Why wouldnt you use a database?

You should use database for persistent data and not for temporary data. Assume that you have to send a message from Sender to Receiver. On Receiving the message, Receiver execute one operation ( receive , process and forget). After processing that message, you don't need that message at all. In this case, storing the message in persistent database is not a right solution.

I fully agree with @Hiram Chirino answer regarding inserting & deleting message in database if you use database instead of messaging system.

Benefits from this article and this article

1. Enterprise integration : Allowing applications built with different languages and on different operating systems to integrate with each other
2. Location transparency : Client applications don’t need to know where the service applications are located
3. Reliable communication – the producers/consumers of messages don’t have to be available at the same time
4. Scaling – can scale horizontally by adding more services
5. Asynchronous communication – a client can fire a message and continue other processing instead of blocking until the service has sent a response;
6. Reduced coupling – the assumptions made by the clients and services are greatly reduced as a result of the previous 5 benefits. A service can change details about itself, including its location, protocol, and availability, without affecting or disrupting the client.

There must be feature ActiveMQ has that databases dont?

There are many. Have a look at documentation page for more details. Have a look at use-cases too.

Have a look at this presentation to understand internals of ActiveMQ.

Stenography

Answer 6

i would like to emphasize the following:

Decoupled : The systems are able to communicate without being connected. Queue lies between systems, one system failure will never affect other as communication is done through Queue. The systems continue to work when they are up.

Recovery support : The messages in Queues itself persisted. The messages can be restored later if Queue fails.

Reliable Communication : Consider a system that process client requests. In normal cases the system receives 100 requests per minute. This system is unreliable when number of request goes beyond average. In such case Queue can manage requests and it can push messages periodically based on system throughput without breaking it.

Asynchronous : Client server communication is non-blocking. Once client sent request to server it can do other operations without waiting for response. When response it received client can handle it anytime.

Hinman

Answer 7

Suppose you have an application which is being used at multiple locations at the same time. Also suppose your application has to handle 1000s of request per minute or something like that so normal db operations cannot handle such operations, Activemq acts as the message processing it takes all the messages into queue , so even if one of your application crashes at one location the other location won't be affected.

Endure

Answer 8

Consider the following generic user scenario

USER SCENARIO

• Customer uploads a text document
• Your application converts the text document into a PDF
• Your application emails the PDF back to the customer

Database for a queue based system In this kind of circumstance, you might consider employing a database for your PDF job line. Regularly you'd make a database table that includes a line with records speaking to PDF demands. You'd at that point put a hail within the table speaking to which state the assignment is in and whether the errand is completed or not.

INSERT INTO pdf_job_queue (name, status, email) VALUES ("White paper", "NEW", "[email protected]");

SELECT * FROM pdf_job_queue WHERE queue = 'resize_queue' AND handled = false ORDER BY date_recived limit 1;

You need to write code to insert the new requests into the database. Code that takes an input from the database, perhaps changes a status column, with values such as "NEW" and "PROCESSING", code that handles the request, more code that again updates the database status field to "FINISHED", and more code to remove the request from the queue.

update pdf_job_queue set Status="FINISHED" where Id = 'SomeId';

To operate effectively, you might need to poll the database quickly and frequently. Of course, this adds a significant load to the database and to your application.

Message Queues When you try to achieve the same by using message queues.

PUSHED IN REAL-TIME Messages from a message line are pushed in real-time rather than occasionally surveyed from a database. An altogether higher volume of concurrent messages can be upheld proficiently employing a message line. Messages in a message line are naturally cleaned up after being gotten.

ACKNOWLEDGMENT An acknowledgment is sent back from the worker to tell the message queue that a particular message has been received and processed and that the message queue is free to delete it. If a worker dies without sending an acknowledgment, the message queue will understand that a message wasn't processed fully and will redeliver it to the queue and to another worker. That way you can be sure that no message is lost.

For message queue systems I would always recommend ActiveMQ due to its easy installation, configuration, and very easy to scale.

Snook