replyCode : 312
gyjx opened this issue · 7 comments
rabbitmq:3.8.3
My problem is that when I use delayed, spring AMQP 2.2.6 returns 312. The code is as follows:
@configuration
public class DelayQueueConfig {
public static final String DELAY_QUEUE = "delay_queue";
public static final String DELAY_ROUT_KEY = "delay_queue_key";
@bean("delayExchange")
public CustomExchange delayExchange() {
Map<String, Object> args = new HashMap<>();
args.put("x-delayed-type", "direct");
return new CustomExchange("delay_exchange", "x-delayed-message", true, false, args);
}
@bean("delayQueue")
public Queue delayQueue() {
return new Queue(DELAY_QUEUE, true, false, false);
}
@bean("delayBinding")
public Binding delayBinding() {
return BindingBuilder.bind(delayQueue()).to(delayExchange()).with(DELAY_ROUT_KEY).noargs();
}
}
send code:
@GetMapping("sendDelay")
public String sendDelay(String exchange, String key) {
log.info("product time:{}", System.currentTimeMillis());
MessageDto messageDto = new MessageDto();
messageDto.setMessageId(UniqueIdGen.getInstance().nextId() + "");
messageDto.setExchange(exchange);
messageDto.setRoutingKey(key);
messageDto.setBusChannel("order");
messageDto.setBody(new OrderBody(UUID.randomUUID().toString()));
messageDto.setExpire(5000);
rabbitMQService.sendDelay(messageDto);
return "ok";
}
returnCallback:
@component
@slf4j
public class RabbitMQConfirmAndReturn implements RabbitTemplate.ReturnCallback {
@Override
public void returnedMessage(Message message, int replyCode, String replyText, String exchange, String routingKey) {
log.info("=================return start========================");
log.info(" message : {} ", message);
log.info(" replyCode : {}", replyCode);
log.info("replyText:{}", replyText);
log.info(" exchange : {}", exchange);
log.info(" routing : {}", routingKey);
log.info("=================return end========================");
}
2020-06-11 16:33:13.601 INFO 18740 --- [nectionFactory1] c.l.r.r.config.RabbitMQConfirmAndReturn : =================return start========================
2020-06-11 16:33:13.601 INFO 18740 --- [nectionFactory1] c.l.r.r.config.RabbitMQConfirmAndReturn : message : (Body:'{"messageId":"455771496965754880","body":{"orderId":"63fc3475-26d1-4265-bc43-77303fea4a2c"},"exchange":"delay_exchange","routingKey":"delay_queue_key","busChannel":"order","expire":5000}' MessageProperties [headers={TypeId=com.luna.rabbitmq.rabbitmqdemo.common.MessageDto}, correlationId=455771496965754880, contentType=application/json, contentEncoding=UTF-8, contentLength=0, receivedDeliveryMode=PERSISTENT, priority=0, receivedDelay=5000, deliveryTag=0])
2020-06-11 16:33:13.602 INFO 18740 --- [nectionFactory1] c.l.r.r.config.RabbitMQConfirmAndReturn : replyCode : 312
2020-06-11 16:33:13.602 INFO 18740 --- [nectionFactory1] c.l.r.r.config.RabbitMQConfirmAndReturn : replyText:NO_ROUTE
2020-06-11 16:33:13.602 INFO 18740 --- [nectionFactory1] c.l.r.r.config.RabbitMQConfirmAndReturn : exchange : delay_exchange
2020-06-11 16:33:13.602 INFO 18740 --- [nectionFactory1] c.l.r.r.config.RabbitMQConfirmAndReturn : routing : delay_queue_key
2020-06-11 16:33:13.602 INFO 18740 --- [nectionFactory1] c.l.r.r.config.RabbitMQConfirmAndReturn : =================return end========================
Thank you for your time.
Team RabbitMQ uses GitHub issues for specific actionable items engineers can work on. GitHub issues are not used for questions, investigations, root cause analysis, discussions of potential issues, etc (as defined by this team).
We get at least a dozen of questions through various venues every single day, often light on details.
At that rate GitHub issues can very quickly turn into a something impossible to navigate and make sense of even for our team. Because GitHub is a tool our team uses heavily nearly every day, the signal/noise ratio of issues is something we care about a lot.
Please post this to rabbitmq-users.
Thank you.
From Limitations in plugin README:
Closely related to the above, the mandatory flag is not supported by this exchange: we cannot be sure that at the future publishing point in time
there is at least one queue we can route to
the original connection is still around to send a basic.return to
If you are not sure what the NO_ROUTE
code means, see Unroutable Messages.
I think this is a potential bug. When I don't use delayed delivery, code 312 won't appear. Please review, thank you!
This plugin does not support mandatory publishing. The Limitations section explains why there is no sensible way to support it. So you will get both a delayed publish and an immediately reported "no route" (a delayed exchange has no bindings) message return.
In case it is still not clear what to do: DO NOT use the mandatory flag with when publishing to this exchange.
This plugin does not support mandatory publishing. The Limitations section explains why there is no sensible way to support it. So you will get both a delayed publish and an immediately reported "no route" (a delayed exchange has no bindings) message return.
In case it is still not clear what to do: DO NOT use the mandatory flag with when publishing to this exchange.
I also encountered this problem. Prometheus gave an alarm and the message could not be routed. In fact, the message was sent to the delay queue normally. Can we consider improving this issue? Normal entry into the delay queue is considered successful, rather than routing failure