Nearly all messaging systems (certainly open source ones) hold either a copy of a persistent message or a reference to a persisted message in memory. This is primarily to try and improve performance, but it also can significantly decrease the complexity of implementation. In fact ActiveMQ version 4 and below worked this - way - by holding references to persisted messages in memory.
However there is a limitation to this approach, no matter how much memory you have at your disposal, you will hit a limit to the number persistent messages a broker can handle at any particular time.
To get around this limitation, ActiveMQ introduced a paging cache - for all message stores (except the memory store) to get the best of both worlds - great performance and the ability to hold 100s of millions of messages in persistent store. ActiveMQ is not limited by memory availability, but by the size of the disk available to hold the persistent messages.
For more information - see below:
A common problem in previous versions of ActiveMQ was running out of RAM buffer when using non-persistent messaging.
Beginning with ActiveMQ 5.0.0, there is a new memory model that allows messages to be paged in from storage when space is available (using Store cursors for persistent messages).
Releases prior to 5.0 kept references in memory for all the messages that could be dispatched to an active Durable Topic Consumer or a Queue. While a reference itself is not large, it does impose a limit on the maximum number of messages that can be pending delivery.
A typical approach for messaging systems dispatching persistent messages is to pull them in batches from long term storage when a client is ready to consume them, using a cursor to maintain the next to dispatch position. This is a robust and very scalable approach, but not the most performant for cases when the consumer(s) can keep up with the producer(s) of messages.
ActiveMQ 5.0 takes a hybrid approach, allowing messages to pass from producer to consumer directly (after the messages have been persisted), but switches back to using cursors if the consumer(s) fall behind.
When Message Consumers are both active and fast - keeping up with the Message Producer(s) - messages are stored and then passed to a dispatch queue in the broker associated with the Consumer:
The default message cursor type in ActiveMQ 5.0 is Store based. It behaves as above. There are two additional types of cursor that could be used: VM Cursor and File based Cursor, described below.
The VM Cursor is how ActiveMQ 4.x works: references to a message are held in memory, and passed to the dispatch queue when needed. This can be very fast, but also has the downside of not being able to handle very slow consumers or consumers that have been inactive for a long time:
The File based Cursor is dervied from the VM Cursor. When memory in the broker reaches its limit, it can page messages to temporary files on disk. This type of cursor can be used when the message store might be relatively slow, but consumers are generally fast. By buffering to disk, it allows the message broker to handle message bursts from producers without resorting to paging in from slow storage:
The store based cursor also handles cursors for non-persistent messages, which are not stored in the message store. Non-persistent messages are passed directly to the cursor, so the store based cursor embeds a file based cursor just for these types of messages:
By default, Store based cursors are used, but it is possible to configure different cursors depending on the destination.
For Topics there is a dispatch queue and pending cursor for every subscriber. It's possible to configure different policies for durable subscribers and transient subscribers - e.g:
Valid Subscriber types are vmCursor and fileCursor. The default is the store based cursor.
For Queues there is a single dispatch Queue and pending Queue for every destination, so configuration is slightly different:
Valid Queue cursor types are storeCursor, vmQueueCursor and fileQueueCursor. The default is the store based cursor