Address settings
Artemis has a unique addressing model that is both powerful and flexible and that offers great performance. The addressing model comprises three main concepts: addresses, queues and routing types.
An address represents a messaging endpoint. Within the configuration, a typical address is given a unique name, 0 or more queues, and a routing type.
A queue is associated with an address. There can be multiple queues per address. Once an incoming message is matched to an address, the message will be sent on to one or more of its queues, depending on the routing type configured. Queues can be configured to be automatically created and deleted.
id: address-settings title: Address settings sidebar_label: Address settings
Configuration settings that are applied on the address level.
A block of settings which will be applied against any addresses with a name that matches a certain wildcard expression.
When match is jms.queue.example for example, the settings would only be applied to any addresses which exactly match the address jms.queue.example. You can also use wildcards to apply settings against many addresses. For example, if you used the match string jms.queue.#, the settings would be applied to all addresses that start with jms.queue. (which would be all JMS queues).
Note that only the most specific match is applied for each address. Some examples from most specific to least specific: jms.queue.example (matches one JMS queue), jms.*.example (matches one JMS queue and one JMS topic), jms.queue.# (matches all JMS queues), jms.# (matches all JMS queues and JMS topics).
Match
A HornetQ wildcard expression contains words delimited by the character . (full stop).
The special characters # and * also have special meaning and can take the place of a word:
- the character
#matches any sequence of zero or more words - the character
*matches a single word
So the wildcard news.europe.# would match news.europe, news.europe.sport, news.europe.politics and news.europe.politics.regional, but would not match news.usa, news.usa.sport nor entertainment.
The wildcard news.* would match news.europe, but not news.europe.sport.
The wildcard news.*.sport would match news.europe.sport and also news.usa.sport, but not news.europe.politics.
Note that addresses of JMS queues are always prefixed with jms.queue. and addresses of JMS topics with jms.topic.. So the wildcard jms.queue.# would match all JMS queues for example.
Required
Last value queue
Defines whether a queue only uses last values or not.
Last value queues are special queues which discard any messages when a newer message with the same value for a well-defined last value property is put in the queue. In other words, a last value queue only retains the last value.
The property name used to identify the last value is _HQ_LVQ_NAME.
Default is false.
Max size
The maximum memory the address could have before applying the address full message policy.
No that this setting applies per address. If you configure a maximum size for an address, that means each matching address will have the maximum size that you specified. It does not mean that the total overall size of all matching addresses is limited to this size.
Default is -1 (no limit).
Address full message policy
This attribute can have one of the following values: page, drop or block and determines what happens when an address reaches its maximum size.
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 block then client message producers will block when they try and send further messages.
Default is page.
Page size
The size of each page file used on the paging system.
The page size must be (significantly) smaller than the max size.
Default is 10485760 (10 MiB)
Page cache max size
The system will keep up to this amount of page files in memory to optimize IO during paging navigation.
Default is 5.
Max delivery attempts
Defines how many time a cancelled message can be redelivered before sending to the dead letter address.
Default is 10.
Redelivery delay
Defines how long to wait before attempting redelivery of a cancelled message.
Default is 0 (no delay between redelivery attempts).
Redelivery multiplier
Multiplier to apply to the time since the last redelivery attempt to compute the time to the next attempt. This allows you to implement an exponential backoff between redelivery attempts.
Default is 1.0, resulting in a fixed delay between redelivery attempts.
Max redelivery delay
Maximum value for the redelivery delay, i.e. this limits how much the delay can increase when using a multiplier that is bigger than 1.0.
Default is equal to the redelivery delay.
Dead letter address
Defines where to send a message that cannot be delivered.
If a dead letter address is not specified, messages will be removed after max delivery attempts unsuccessful attempts.
Default is empty.
Expiry delay
Defines the expiration time that will be used for messages which are using the default expiration time (i.e. 0).
For example, if expiry delay is set to 10 and a message which is using the default expiration time (i.e. 0) arrives, then its expiration time of 0 will be changed to 10. However, if a message which is using an expiration time of 20 arrives, then its expiration time will remain unchanged.
Setting expiry-delay to -1 will disable this feature.
Default is -1.
Expiry address
Defines where to send a message that has expired.
If messages are expired and no expiry address is specified, messages are simply removed from the queue and dropped.
Default is empty.
Redistribution delay
Defines the delay in milliseconds after the last consumer is closed on a queue before redistributing messages from that queue to other nodes of the cluster which do have matching consumers. A delay of zero means the messages will be immediately redistributed. A value of -1 signifies that messages will never be redistributed.
It often makes sense to introduce a delay before redistributing as it's a common case that a consumer closes but another one quickly is created on the same queue, in such a case you probably don't want to redistribute immediately since the new consumer will arrive shortly.
Default is -1 (no redistribution).
Send to DLA on no route
If a message is sent to an address, but the server does not route it to any queues, for example, there might be no queues bound to that address, or none of the queues have filters that match, then normally that message would be discarded. However if this parameter is set to true for that address, if the message is not routed to any queues it will instead be sent to the dead letter address (DLA) for that address, if it exists.
Default is false.
Message counter history limit
How many days to keep message counter history.
Default is 0.
A slow consumer with a server-side queue (e.g. JMS topic subscriber) can pose a significant problem for broker performance. If messages build up in the consumer's server-side queue then memory will begin filling up and the broker may enter paging mode which would impact performance negatively. However, criteria can be set so that consumers which don't acknowledge messages quickly enough can potentially be disconnected from the broker which in the case of a non-durable JMS subscriber would allow the broker to remove the subscription and all of its messages freeing up valuable server resources.
By default the server will not detect slow consumers.
The calculation to determine whether or not a consumer is slow only inspects the number of messages a particular consumer has acknowledged. It doesn't take into account whether or not flow control has been enabled on the consumer, whether or not the consumer is streaming a large message, etc. The message production rate is also assumed to meet or exceed the slow consumer threshold. Keep this in mind when configuring slow consumer detection.
Please note that slow consumer checks are performed using the scheduled thread pool and that each queue on the broker with slow consumer detection enabled will cause a new entry in the internal java.util.concurrent.ScheduledThreadPoolExecutor instance. If there are a high number of queues and the slow consumer check period is relatively low then there may be delays in executing some of the checks. However, this will not impact the accuracy of the calculations used by the detection algorithm.
Slow consumer threshold
The minimum rate of message consumption allowed before a consumer is considered "slow." Measured in messages-per-second.
Default is -1 (i.e. disabled).
Slow consumer policy
What should happen when a slow consumer is detected.
Kill will kill the consumer's connection (which will obviously impact any other client threads using that same connection).
Notify will send a CONSUMER_SLOW management notification which an application could receive and take action with.
Default is notify.
Slow consumer check period
How often to check for slow consumers on a particular queue. Measured in seconds.
Default is 5.