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.
2.0 KiB
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 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:
<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.
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:
<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
for more details on this. You could also use a ring queue.