mirror of
https://github.com/apache/activemq-artemis.git
synced 2025-02-10 03:55:58 +00:00
2dc76bd9f4
Mainly refactoring the address docs. This commit has the following changes: - Remove examples for discouraged use-cases (e.g. using anycast and multicast on the same address). - Reword to use configuration terms wherever possible. For example, instead of saying "point-to-point" (which is not a configuration term) say "anycast". References to things like "point-to-point" and "publish-subscribe" are still there since users are familiar with these terms. They're just used much less often. - Remove duplicate explanation of exclusive queues. - Remove duplicate explanation of auto-create and auto-delete elements. - Re-create graphics and include the master SVGs for potential updates later. - Give non-destructive queues its own chapter. - Add details about specifying routing type using a message property. - Update the styling on the user manual's cover page to look better. - Lots of re-wording for clarity's sake. - Re-order sub-sections for clarity's sake. - Break up the address model and the settings documentation. The settings documentation is large and deserves its own chapter. The original anchor link is still available with a link to the new chapter. In general the address-specific documentation should be much more clear, concise, and consistent now.
53 lines
2.0 KiB
Markdown
53 lines
2.0 KiB
Markdown
# Non-Destructive Queues
|
|
|
|
When a consumer attaches to a queue, the normal behaviour is that messages are
|
|
sent to that consumer are acquired exclusively by that consumer, and when the
|
|
consumer acknowledges them, the messages are removed from the queue.
|
|
|
|
Another common pattern is to have queue "browsers" which send all messages to
|
|
the browser, but do not prevent other consumers from receiving the messages,
|
|
and do not remove them from the queue when the browser is done with them. Such
|
|
a browser is an instance of a "non-destructive" consumer.
|
|
|
|
If every consumer on a queue is non destructive then we can obtain some
|
|
interesting behaviours. In the case of a [last value
|
|
queue](last-value-queues.md) then the queue will always contain the most up to
|
|
date value for every key.
|
|
|
|
A queue can be created to enforce all consumers are non-destructive using the
|
|
following queue configuration:
|
|
|
|
```xml
|
|
<address name="foo.bar">
|
|
<multicast>
|
|
<queue name="orders1" non-destructive="true" />
|
|
</multicast>
|
|
</address>
|
|
```
|
|
|
|
Or on auto-create when using the JMS client by using address parameters when
|
|
creating the destination used by the consumer.
|
|
|
|
```java
|
|
Queue queue = session.createQueue("my.destination.name?non-destructive=true");
|
|
Topic topic = session.createTopic("my.destination.name?non-destructive=true");
|
|
```
|
|
|
|
Also the default for all queues under and address can be defaulted using the
|
|
`address-setting` configuration:
|
|
|
|
```xml
|
|
<address-setting match="nonDestructiveQueue">
|
|
<default-non-destructive>true</default-non-destructive>
|
|
</address-setting>
|
|
```
|
|
|
|
By default, `default-non-destructive` is `false`.
|
|
|
|
## Limiting the Size of the Queue
|
|
|
|
For queues other than last-value queues, having only non-destructive consumers
|
|
could mean that messages would never get deleted, leaving the queue to grow
|
|
without constraint. To prevent this you can use the ability to set a default
|
|
`expiry-delay`. See [expiry-delay](message-expiry.md#configuring-expiry-delay)
|
|
for more details on this. You could also use a [ring queue](ring-queues.md). |