- RabbitMQ Cookbook
- Sigismondo Boschi Gabriele Santomaggio
- 575字
- 2021-07-19 18:52:50
How to let messages expire on specific queues
In this recipe, we show a second way to specify a message TTL. This time, it is not a property of the message itself but of the queue where the message is buffered. In this case, the producer simply publishes normal messages to the exchange, so it's possible to bind both a standard queue and a queue where messages expire.
To remark on this aspect, here it's the consumer that creates the customized queue. The producer is quite standard.
As in the preceding recipe, you can find the three sources at Chapter02/Recipe02/Java/src/rmqexample.
Getting ready
To use this recipe, we need to set up the Java development environment, as indicated in the Introduction section of Chapter 1, Working with AMQP.
How to do it...
We are now showing the needed steps to create a queue with a specific message TTL. In our explanatory example, the following steps are performed in the Consumer.java file:
- Create or declare the exchange as follows:
channel.exchangeDeclare(exchange, "direct", false);
- Create or declare the queue, specifying a 10,000 milliseconds timeout to the
x-message-ttloptional argument as follows:Map<String, Object> arguments = new HashMap<String, Object>(); arguments.put("x-message-ttl", 10000); channel.queueDeclare(queue, false, false, false, arguments); - Bind the queue to the exchange where the messages are going to come from:
channel.queueBind(queue, exchange, routingKey);
How it works...
Again, in this example, we are supposed to have a producer that sends JVM statistics to RabbitMQ for eventual analysis. Eventual because the Producer.java file sends them to an exchange and messages will be lost if there are no consumers connected.
A consumer that wants to monitor and analyze those statistics has the following three choices:
- To bind with a temporary queue, invoking
channel.queueDeclare()without arguments - To bind with a non-autodelete, named queue
- To bind with a non-autodelete, named queue and specifying
x-message-ttl, as shown in step 2.
In the first case, the consumer will get real-time statistics only but it won't be able to perform an analysis on any data sent when it's down.
In the second case, to let the consumer get messages sent when it's down, it can use a named queue (persistent too eventually). But if it is down for a long time, when restarted, it will have a huge backlog to recover from before it starts being effective as a monitor. So, it would probably just trash most of the old messages in the queue.
The third option, the argument of our recipe, is just this, but trashing old messages is performed by RabbitMQ itself with benefits for both the consumer and the broker itself.
There's more...
When setting a per-queue TTL, as seen in this recipe, messages are not dropped (or dead lettered, refer to the Managing rejected or expired messages recipe later in this chapter) as soon as the timeout arrives, but only when a consumer tries to consume them. At this point, these messages are silently dropped and the first ready, not expired message is sent to the consumer.
When using queue TTL, this is a minor difference, but using per-message TTL, as seen in the previous recipe, it's possible to have expired messages in the broker queue behind regular messages.
In this case, those expired messages still occupy resources (memory) and are counted in the broker statistics, until they won't reach the head of the queue.
See also
The expired messages can be recovered in this case too. Refer to the Managing rejected or expired messages recipe.
- Learn ECMAScript（Second Edition）
- Android Wearable Programming
- 兩周自制腳本語言
- Groovy for Domain：specific Languages（Second Edition）
- Mastering Kali Linux for Web Penetration Testing
- 零基礎學Python數據分析（升級版）
- Building Minecraft Server Modifications
- Python數據可視化之Matplotlib與Pyecharts實戰
- 零基礎趣學C語言
- 用戶體驗可視化指南
- JavaScript+jQuery網頁特效設計任務驅動教程
- Mastering Gephi Network Visualization
- INSTANT Apache ServiceMix How-to
- STM8實戰
- 每個人的Python：數學、算法和游戲編程訓練營