0. 想用笔记本玩 2k14, 但是键盘弱不禁风
我想要有一个可以本地安装IDE的平板电脑,转了一圈,还是感觉尚不成熟
本章节继续以 客户端 的视角,了解RabbitMQ中的 应答消息
4.1.9. Modifying Messages - Compression and More
A number of extension points exist. They let you perform some processing on a message
- either before it is sent to RabbitMQ
- or immediately after it is received.
4.1.10. Request/Reply Messaging
The AmqpTemplate
also provides a variety of sendAndReceive
methods that accept the same argument options
that were described earlier for the one-way(单向) send operations (exchange, routingKey, and Message).
Those methods are quite(比较) useful for request-reply scenarios, since they handle the configuration of the necessary reply-to property
before sending and can listen for the reply message on an exclusive queue that is created internally for that purpose.
Reply Timeout
By default, the send and receive methods timeout after five seconds and return null. You can modify this behavior by setting the replyTimeout
property.
If you set the mandatory
property to true
(or the mandatory-expression
evaluates to true for a particular message),
If the message cannot be delivered to a queue, an AmqpMessageReturnedException
is thrown.
A replyTimedOut
method has been added, letting subclasses be informed(告知) of the timeout so that they can clean up any retained state.
you use the default DirectReplyToMessageListenerContainer
, you can add an error handler by setting the template’s replyErrorHandler
property.
RabbitMQ Direct reply-to
The RabbitMQ server supports direct
reply-to
. This eliminates(消除) the main reason for a fixed reply queue
(to avoid the need to create a temporary queue for each request).
direct reply-to
is used by default (if supported by the server) instead of creating temporary reply queues.
When no replyQueue is provided (or it is set with a name ofamq.rabbitmq.reply-to
),
the RabbitTemplate automatically detects whether direct reply-to is supported and either uses it or falls back to using a temporary reply queue.
When using direct reply-to, a reply-listener is not required and should not be configured.
Reply listeners are still supported with named queues (other than amq.rabbitmq.reply-to
), allowing control of reply concurrency and so on.
If you wish to use a temporary, exclusive, auto-delete queue for each reply, set the useTemporaryReplyQueues
property to true. This property is ignored if you set a replyAddress.
The template uses a DirectReplyToMessageListenerContainer
instead, letting the consumers be reused.
The template still takes care of correlating the replies, so there is no danger of a late reply going to a different sender.
If you want to revert to the previous behavior, set the useDirectReplyToContainer
The AsyncRabbitTemplate
has no such option. It always used a DirectReplyToContainer
for replies when direct reply-to is used.
the template has a new property useChannelForCorrelation
. When this is true, the server does not have to copy the correlation id from the request message headers to the reply message.
Instead, the channel used to send the request is used to correlate the reply to the request.
Message Correlation With A Reply Queue
When using a fixed reply queue (other than amq.rabbitmq.reply-to
), you must provide correlation data so that replies can be correlated to requests.
By default, the standard correlationId
property is used to hold the correlation data. However, if you wish to use a custom property to hold correlation data
Explicitly setting the attribute to correlationId
is the same as omitting(省略) the attribute. The client and server must use the same header for correlation data.
Spring AMQP version 1.1 used a custom property called spring_reply_correlation
for this data. If you wish to revert to this behavior with the current version
(perhaps to maintain compatibility with another application using 1.1), you must set the attribute to spring_reply_correlation
By default, the template generates its own correlation ID (ignoring any user-supplied value). If you wish to use your own correlation ID
, set the RabbitTemplate instance’s userCorrelationId
property to true.
The correlation ID must be unique to avoid the possibility of a wrong reply being returned for a request.
Reply Listener Container
When using RabbitMQ versions prior to 3.4.0, a new temporary queue is used for each reply.
However, a single reply queue can be configured on the template,
which can be more efficient and also lets you set arguments on that queue.
In this case, however, you must also provide a <reply-listener/>
sub element.
This element provides a listener container for the reply queue, with the template being the listener.
@Bean
public RabbitTemplate amqpTemplate() {
RabbitTemplate rabbitTemplate = new RabbitTemplate(connectionFactory());
rabbitTemplate.setMessageConverter(msgConv());
rabbitTemplate.setReplyAddress(replyQueue().getName());
rabbitTemplate.setReplyTimeout(60000);
rabbitTemplate.setUseDirectReplyToContainer(false);
return rabbitTemplate;
}
@Bean
public SimpleMessageListenerContainer replyListenerContainer() {
SimpleMessageListenerContainer container = new SimpleMessageListenerContainer();
container.setConnectionFactory(connectionFactory());
container.setQueues(replyQueue());
container.setMessageListener(amqpTemplate());
return container;
}
@Bean
public Queue replyQueue() {
return new Queue("my.reply.queue");
}
When the reply times out (
replyTimeout
), the sendAndReceive() methods return null.
Async Rabbit Template
AsyncRabbitTemplate
has similar sendAndReceive (and convertSendAndReceive) methods to those on the AmqpTemplate
.
However, instead of blocking, they return a ListenableFuture
.
The publisher confirm is discarded(抛弃) if it is received after the reply, since the reply implies(意味着) a successful publish.
Spring Remoting with AMQP
This feature is deprecated and will be removed in 3.0. It has been superseded(取代) for a long time by Handling Exceptions
with thereturnExceptions
being set to true, and configuring aRemoteInvocationAwareMessageConverterAdapter
on the sending side.