LibraryLink ToToggle FramesPrintFeedback

Types of Cursors

Store-based cursors are the default cursor implementation used by ActiveMQ. Store-based cursors are a hybrid implementation that offers the robustness of typical cursor implementations and the speed of in-memory message reference implementations.

Typically messaging systems will pull persistent messages from long-term storage in a batch when a client is ready to consume them. A cursor will be used to maintain the position for the next batch of messages. While this approach scales well and provides excellent robustness, it does not perform well when message consumers keep pace with message producers.

As shown in Figure 4.1, store-based cursors address the fast consumer case by skipping the message cursor. When a message consumer is keeping pace with the message producers, persistent messages are written to the message store and moved directly into a dispatch queue for the consumer.

When a consumer starts with a back log of messages or falls behind its message producers, ActiveMQ changes the strategy used to dispatch messages. As shown in Figure 4.2, messages are held in the message store and fed into the consumer's dispatch queue using the pending cursor.

When speed is the top priority and the consumers can definitely keep pace with the message producers, VM cursors could be the best approach. In this approach, shown in Figure 4.3, messages are written to the persistent store and then also stored in the pending cursor which is held completely in memory. The messages are fed into the dispatch queue from the pending cursor.

Because the message are dispatched from active memory when using VM cursors, this method is exceptionally fast. However, if the number of unconsumed messages gets large the producers will be throttled to avoid exceeding the available memory.

File-based cursors are a variation of VM cursors that provides a buffer against running out of memory when a consumer falls behind. As shown in Figure 4.4, the broker pages messages out to a temporary file when the broker's memory limit is reached.

Using a temporary file cushions the broker against situations where a consumer occasionally falls behind or messages are produced in a burst. The broker uses the temporary file instead of resorting to using slower persistent storage.

File-based cursors do not scale well when consumers are frequently behind by a large margin. It is also not ideal when a fast long term message store is available.