Question

我正在测试发布商 - ＆gt; Exchange-＆gt;队列和侦听器模型的 ConfirmCallback ， ReturnCallback 流程。我已将publisherConfirms，publisherReturns，强制设置为true。我向具有无效队列名称的现有交易所发布了一条新消息。正如所料，我收到了ReturnCallback.returnedMessage方法的回调。但是我也收到了对ConfirmCallback.confirm方法的回调。据我所知，由于队列名称无效，只有ReturnCallback.returnedMessage方法应该已收到回调。为什么调用ConfirmCallback.confirm方法？我已多次测试该场景，并且我收到了相同的结果。请查看下面的代码片段和日志文件以供您了解，如果出现问题请告诉我。

rabbitTemplate.setMandatory(true);
            rabbitTemplate.setConfirmCallback(new ConfirmCallback() {

                @Override
                public void confirm(final CorrelationData correlationData, final boolean ack,
                        final String cause) {
                    System.out.println("confirmCallback received with correlationData, ack, cause" + correlationData+ cause + ack);
                    if (null != confirmCallbackUser) {
                            confirmCallbackUser.confirm(correlationData.getId(), ack, cause);
                    }    });


            rabbitTemplate.setMandatory(true);
            rabbitTemplate.setReturnCallback(new RabbitTemplate.ReturnCallback() 
                @Override
                public void returnedMessage(final Message message, final int replyCode,
                        final String replyText, final String exchange, final String routingKey) {
                    Message msg = new Message(message);
                    try {
                        System.out.println("returnCallBackUser received with message, replyCode, replyText,  exchange, routingKey" + message + replyCode + replyText+  exchange + routingKey);
                        returnCallBackUser.returnedMessage(msg, replyCode, replyText, exchange,
                                routingKey);
                    } catch (MessagingException e) {
                        System.out.println("returnCallBackUser exception : " + e.getMessage());
   e.printStackTrace();
                    }
                    System.err.println(" Message Returned");

                }

日志

40053 [https-openssl-nio-8443-exec-6] DEBUG c.s.n.f.s.messaging.MessImpl **- Control reached send()** 
40056 [https-openssl-nio-8443-exec-6] DEBUG o.s.a.r.c.CachingConnectionFactory - Creating cached Rabbit Channel from PublisherCallbackChannelImpl: AMQChannel(amqp://guest@127.0.0.1:5672/,2) 
40056 [https-openssl-nio-8443-exec-6] DEBUG o.s.a.r.s.PublisherCallbackChannelImpl - Added listener org.springframework.amqp.rabbit.core.RabbitTemplate@7c8f1db1 
40057 [https-openssl-nio-8443-exec-6] DEBUG o.s.amqp.rabbit.core.RabbitTemplate - Added pubsub channel: Cached Rabbit Channel: PublisherCallbackChannelImpl: AMQChannel(amqp://guest@127.0.0.1:5672/,2), conn: Proxy@6bc6056e Shared Rabbit Connection: SimpleConnection@69225b5 [delegate=amqp://guest@127.0.0.1:5672/, localPort= 60962] to map, size now 1 
40057 [https-openssl-nio-8443-exec-6] DEBUG o.s.amqp.rabbit.core.RabbitTemplate **- Executing callback on RabbitMQ Channel: Cached Rabbit Channel:** PublisherCallbackChannelImpl: AMQChannel(amqp://guest@127.0.0.1:5672/,2), conn: Proxy@6bc6056e Shared Rabbit Connection: SimpleConnection@69225b5 [delegate=amqp://guest@127.0.0.1:5672/, localPort= 60962] 
40061 [https-openssl-nio-8443-exec-6] DEBUG o.s.amqp.rabbit.core.RabbitTemplate **- Publishing message on exchange [ControlExchange], routingKey = [invalidQueue]** 
40064 [https-openssl-nio-8443-exec-6] DEBUG c.s.n.f.s.messaging.MessImpl - **Control moving out of send()** 
***returnCallBackUser received with message,*** replyCode, replyText,  exchange, routingKey(Body:'[B@294b5bb4(byte[91])' MessageProperties [headers={IDENTITY=TOMCAT_CONTROL}, timestamp=null, messageId=null, userId=null, receivedUserId=null, appId=null, clusterId=null, type=null, correlationId=[80, 114, 111, 100, 117, 99, 101, 114], correlationIdString=null, replyTo=ControlExchange/ComAckQueue, contentType=application/octet-stream, contentEncoding=null, contentLength=0, deliveryMode=null, receivedDeliveryMode=PERSISTENT, expiration=null, priority=0, redelivered=null, receivedExchange=null, receivedRoutingKey=null, receivedDelay=null, deliveryTag=0, messageCount=null, consumerTag=null, consumerQueue=null])312NO_ROUTEControlExchangeinvalidQueue
40066 [AMQP Connection 127.0.0.1:5672] INFO  c.s.n.f.s.m.CallBackRecReplyInterfaceTemplate - Message {"Test":"abcd","Role":"abcd","Id":"1111","request":"Accepted","De":"invalidQueue"} replyCode-> 312breplyText-> NO_ROUTE exchange-> Exchange routingKey->  invalidQueue
 **Message Returned**
40066 [AMQP Connection 127.0.0.1:5672] DEBUG o.s.a.r.s.PublisherCallbackChannelImpl - **PublisherCallbackChannelImpl: AMQChannel(amqp://guest@127.0.0.1:5672/,2) PC:Ack:1:false** 
40067 [AMQP Connection 127.0.0.1:5672] DEBUG o.s.a.r.s.PublisherCallbackChannelImpl - **Sending confirm PendingConfirm [correlationData=CorrelationData [id=corrlDat]] 
confirmCallback received with correlationData, ack, causeCorrelationData [id=corrlDat]nulltrue**
40067 [AMQP Connection 127.0.0.1:5672] INFO  c.s.n.f.s.m.CallbackConfirmImplTempl - **ACK->truecause->nullcorr id corrlDat 
40067 [AMQP Connection 127.0.0.1:5672] INFO  c.s.n.f.s.messaging.MessagingImpl - ACK->truecause->nullcorr id corrlDat**

Answer 1

Publisher确认代理完成处理后的调用。如果队列错误，经纪人会在确认该消息何时无法路由时发送确认。请参阅＆＃34中的documentation;何时确认消息＆＃34;。

发布到无效队列时，会调用ReturnCallback，但为什么ConfirmCallback会调用相同的消息

1 个答案: