2014-12-11 07:17:29 -05:00
# Paging
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
Apache ActiveMQ Artemis transparently supports huge queues containing millions
of messages while the server is running with limited memory.
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
In such a situation it's not possible to store all of the queues in memory at
any one time, so Apache ActiveMQ Artemis transparently *pages* messages into
and out of memory as they are needed, thus allowing massive queues with a low
memory footprint.
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
Apache ActiveMQ Artemis will start paging messages to disk, when the size of
all messages in memory for an address exceeds a configured maximum size.
2014-12-04 10:25:29 -05:00
2016-09-02 16:30:44 -04:00
The default configuration from Artemis has destinations with paging.
2014-12-04 10:25:29 -05:00
2014-12-11 07:17:29 -05:00
## Page Files
2014-12-04 10:25:29 -05:00
Messages are stored per address on the file system. Each address has an
2018-03-09 10:07:38 -05:00
individual folder where messages are stored in multiple files (page files).
Each file will contain messages up to a max configured size
(`page-size-bytes`). The system will navigate the files as needed, and it
will remove the page file as soon as all the messages are acknowledged up to
that point.
2014-12-04 10:25:29 -05:00
Browsers will read through the page-cursor system.
2018-03-09 10:07:38 -05:00
Consumers with selectors will also navigate through the page-files and it will
ignore messages that don't match the criteria.
2015-02-26 22:20:17 -05:00
> *Warning:*
>
2018-03-09 10:07:38 -05:00
> When you have a queue, and consumers filtering the queue with a very
> restrictive selector you may get into a situation where you won't be able to
> read more data from paging until you consume messages from the queue.
>
> Example: in one consumer you make a selector as 'color="red"' but you only
> have one color red 1 millions messages after blue, you won't be able to
> consume red until you consume blue ones.
2015-02-26 22:20:17 -05:00
>
2018-03-09 10:07:38 -05:00
> This is different to browsing as we will "browse" the entire queue looking
> for messages and while we "depage" messages while feeding the queue.
2015-02-26 22:20:17 -05:00
2014-12-04 10:25:29 -05:00
2018-03-08 15:46:38 -05:00
### Configuration
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
You can configure the location of the paging folder in `broker.xml` .
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
- `paging-directory` Where page files are stored. Apache ActiveMQ Artemis will
create one folder for each address being paged under this configured
location. Default is `data/paging` .
2014-12-04 10:25:29 -05:00
2014-12-11 07:17:29 -05:00
## Paging Mode
2014-12-04 10:25:29 -05:00
As soon as messages delivered to an address exceed the configured size,
that address alone goes into page mode.
2018-03-09 10:07:38 -05:00
> **Note:**
2014-12-04 10:25:29 -05:00
>
2018-03-09 10:07:38 -05:00
> Paging is done individually per address. If you configure a max-size-bytes
> for an address, that means each matching address will have a maximum size
> that you specified. It DOES NOT mean that the total overall size of all
> matching addresses is limited to max-size-bytes.
2014-12-04 10:25:29 -05:00
2018-03-08 15:46:38 -05:00
### Configuration
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
Configuration is done at the address settings in `broker.xml` .
2014-12-04 10:25:29 -05:00
2018-03-08 15:46:38 -05:00
```xml
< address-settings >
< address-setting match = "jms.someaddress" >
< max-size-bytes > 104857600< / max-size-bytes >
< page-size-bytes > 10485760< / page-size-bytes >
< address-full-policy > PAGE< / address-full-policy >
< / address-setting >
< / address-settings >
```
2014-12-04 10:25:29 -05:00
2018-11-06 08:52:57 -05:00
> **Note:**
> The [management-address](management.md#configuring-management)
> settings cannot be changed or overridden ie management
> messages aren't allowed to page/block/fail and are considered
> an internal broker management mechanism.
> The memory occupation of the [management-address](management.md#configuring-management)
> is not considered while evaluating if [global-max-size](#global-max-size)
> is hit and can't cause other non-management addresses to trigger a
> configured `address-full-policy`.
2014-12-04 10:25:29 -05:00
This is the list of available parameters on the address settings.
2018-03-09 10:07:38 -05:00
Property Name|Description|Default
---|---|---
`max-size-bytes` |What's the max memory the address could have before entering on page mode.|-1 (disabled)
`page-size-bytes` |The size of each page file used on the paging system|10MB
`address-full-policy` |This must be set to `PAGE` for paging to enable. If the value is `PAGE` then further messages will be paged to disk. If the value is `DROP` then further messages will be silently dropped. If the value is `FAIL` then the messages will be dropped and the client message producers will receive an exception. If the value is `BLOCK` then client message producers will block when they try and send further messages.|`PAGE`
`page-max-cache-size` |The system will keep up to `page-max-cache-size` page files in memory to optimize IO during paging navigation.|5
2014-12-04 10:25:29 -05:00
2016-09-02 16:30:44 -04:00
## Global Max Size
2018-03-09 10:07:38 -05:00
Beyond the `max-size-bytes` on the address you can also set the global-max-size
on the main configuration. If you set `max-size-bytes` = `-1` on paging the
`global-max-size` can still be used.
2016-09-02 16:30:44 -04:00
2018-03-09 10:07:38 -05:00
When you have more messages than what is configured `global-max-size` any new
produced message will make that destination to go through its paging policy.
2016-09-02 16:30:44 -04:00
2018-03-09 10:07:38 -05:00
`global-max-size` is calculated as half of the max memory available to the Java
Virtual Machine, unless specified on the `broker.xml` configuration.
2017-04-06 15:03:25 -04:00
2014-12-11 07:17:29 -05:00
## Dropping messages
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
Instead of paging messages when the max size is reached, an address can also be
configured to just drop messages when the address is full.
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
To do this just set the `address-full-policy` to `DROP` in the address settings
2014-12-04 10:25:29 -05:00
2014-12-11 07:17:29 -05:00
## Dropping messages and throwing an exception to producers
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
Instead of paging messages when the max size is reached, an address can also be
configured to drop messages and also throw an exception on the client-side when
the address is full.
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
To do this just set the `address-full-policy` to `FAIL` in the address settings
2014-12-04 10:25:29 -05:00
2014-12-11 07:17:29 -05:00
## Blocking producers
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
Instead of paging messages when the max size is reached, an address can also be
configured to block producers from sending further messages when the address is
full, thus preventing the memory being exhausted on the server.
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
When memory is freed up on the server, producers will automatically unblock and
be able to continue sending.
2014-12-04 10:25:29 -05:00
To do this just set the `address-full-policy` to `BLOCK` in the address
settings
2018-03-09 10:07:38 -05:00
In the default configuration, all addresses are configured to block producers
after 10 MiB of data are in the address.
2014-12-04 10:25:29 -05:00
2017-03-09 05:11:48 -05:00
## Caution with Addresses with Multiple Multicast Queues
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
When a message is routed to an address that has multiple multicast queues bound
to it, e.g. a JMS subscription in a Topic, there is only 1 copy of the message
in memory. Each queue only deals with a reference to this. Because of this the
memory is only freed up once all queues referencing the message have delivered
it.
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
If you have a single lazy subscription, the entire address will suffer IO
performance hit as all the queues will have messages being sent through an
extra storage on the paging system.
2014-12-04 10:25:29 -05:00
For example:
2018-03-09 10:07:38 -05:00
- An address has 10 multicast queues
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
- One of the queues does not deliver its messages (maybe because of a
slow consumer).
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
- Messages continually arrive at the address and paging is started.
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
- The other 9 queues are empty even though messages have been sent.
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
In this example all the other 9 queues will be consuming messages from the page
system. This may cause performance issues if this is an undesirable state.
2014-12-04 10:25:29 -05:00
2016-09-02 16:30:44 -04:00
## Max Disk Usage
2018-03-09 10:07:38 -05:00
The System will perform scans on the disk to determine if the disk is beyond a
configured limit. These are configured through `max-disk-usage` in percentage.
Once that limit is reached any message will be blocked. (unless the protocol
doesn't support flow control on which case there will be an exception thrown
and the connection for those clients dropped).
2016-09-02 16:30:44 -04:00
2014-12-11 07:17:29 -05:00
## Example
2014-12-04 10:25:29 -05:00
2018-03-09 10:07:38 -05:00
See the [Paging Example ](examples.md#paging ) which shows how to use paging with
Apache ActiveMQ Artemis.