Does HornetQ solve this problem?

[ccargill]

I am currently looking for a replacement for ActiveMQ due to its inability to effectively handle my use case. I am considering switching to HornetQ, but I am having difficulty assessing whether it satisfies my requirements.

Essentially, I have one consumer and many assets (producers) that can connect as little as 15 seconds in a day, or in other cases, be completely reliable. For the reliable use case, I have little concern. The issue I ran into with ActiveMQ was that the transfer rates would always far exceed my ability to write to the database on the consumer. Essentially, the following would occur.

• Receive some data while concurrently writing to Db
• Finish write to database
• Acknowledge all data as a transaction
• Repeat
• Disconnect (and likely have to rollback a transaction that contained data written to the database)

However, ideally what I would like to happen is the following.

• Receive data for 15 seconds while concurrently writing to DB
• Disconnect
• Continue writing to DB
• Reconnect
• Acknowledge written data and continue receiving

There will only ever be one consumer for all of the producers. Thus, instead of worrying about distribution of data among multiple consumers, the emphasis becomes ensuring efficient and persistent offload of data even through connection failure.

Is this possible with HornetQ? If so, what kind of configuration settings would I need?

[jbertram]

Before I get to your question you should know that back in June of 2015 the HornetQ code-base was donated to the Apache ActiveMQ community.  Since then no development has occurred on HornetQ itself.  However, the HornetQ code-base lives on as the ActiveMQ Artemis broker.  Over the last 18 months Artemis has evolved quite a bit to support many new features through 7 different releases (from 1.0.0 up until the latest 1.5.1).  I answer your question under the assumption you'd be using the latest release of Artemis rather than HornetQ.

Artemis ties transactions to sessions which are in turn tied to connections so if your consumer starts a transaction and then explicitly closes its connection then the transaction on the server will be aborted.  However, there is a kind of grace period for clients on unreliable connections such that the server will maintain its session data until the client can reconnect (assuming the client was configured to reconnect automatically).  You can read more about this in the "Cleaning up Dead Connection Resources on the Server" section of the Artemis documentation.

I doubt if any general-purpose message broker would explicitly support the kind of functionality you're looking for where you can start a transaction, disconnect, and then reconnect later at some arbitrary time (or potentially never) to commit or rollback that transaction.  Long running transactions are typically viewed as an anti-pattern as the longer they are around presumably the more resources/data will be involved in the transaction and the the more likely it is that something will fail and therefore undo all the work.