HornetQ Persistence Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 5: Line 5:
=Overview=
=Overview=


This article provides a high level overview of the HornetQ persistence concepts. It will describe what kind of data is persisted, as well as where and when. It will also discuss paging, which is a protection mechanism against running out of memory.
This article provides a high level overview of the HornetQ persistence concepts. It will describe what kind of data is persisted, as well as where and when. It will also discuss paging, which is a protection mechanism against running out of memory; persistence is relevant in this context because messages that do not fit in memory go to the filesystem, even if the messages themselves are marked as non-persistent.


=There is No Database=
=There is No Database=

Revision as of 22:16, 11 March 2016

Internal

Overview

This article provides a high level overview of the HornetQ persistence concepts. It will describe what kind of data is persisted, as well as where and when. It will also discuss paging, which is a protection mechanism against running out of memory; persistence is relevant in this context because messages that do not fit in memory go to the filesystem, even if the messages themselves are marked as non-persistent.

There is No Database

Unlike other messaging systems, which do offer the option of storing message data in a relational database, HornetQ does not. For reasons that led to this decision see https://developer.jboss.org/thread/153581. More details in "Messaging persistence in EAP 6.x" https://access.redhat.com/solutions/226743.

What Does HornetQ Persist?

Persistent Messages

All persistent messages must be stored on persistent storage, as mandated by the JMS specification. This is necessary to protect against messaging system failure: a persistent message can be presumably recovered from the persistent storage and re-sent.

Bindings

JMS

Large Messages

Non Persistent Messages

Journal

When a node is started for the first time it persists a unique identifier into its journal directory. This ID is needed for proper formation of clusters.