Spring Integration error "no output-channel or replyChannel header available"

Question

I am not sure why I am getting the exception

Caused by: org.springframework.messaging.core.DestinationResolutionException: no output-channel or replyChannel header available

Its just a simple IntegrationFlow but not sure what am I missing here in the code below.

  @Bean
  Exchange messageExchange() {
    return ExchangeBuilder
        .directExchange("attr")
        .durable(true)
        .build();
  }

  @Bean
  Queue queue() {
    return QueueBuilder
        .durable("attr_queue")
        .build();
  }

  @Bean
  Binding binding() {
    return BindingBuilder
        .bind(queue())
        .to(messageExchange())
        .with("attr_queue")
        .noargs();
  }

  @Bean
  IntegrationFlow deltaFlow(ConnectionFactory connectionFactory) {
    return IntegrationFlows.from(Amqp
        .inboundAdapter(connectionFactory, queue()))
        .handle(String.class, (payload, headers) -> {
          if (payload.isEmpty()) {
            log.info("Payload empty");
          } else {
            log.info("Payload : " + payload);
          }
          return payload;
        })
        .get();
  }

I was trying to get my hands on Spring Integration and was not sure why I am getting this exception. All I'm trying to do is to read from a queue using an inboundAdapter and just log it to the console. The code runs fine, but when I publish a message to the queue, I get this exception. Do I have to specify a replyChannel or output-channel always when using Amqp adapters?

Answer 1

No, that’s not AMQP Channel Adapter problem. Please, look at your handle() - you return something there. And there is nothing afterwards to handle that return. So, where should a reply go? Right, into the replyChannel header. But wait , there is no one because there is nothing to wait for the reply - the Channel Adapter is one-way component.

Since you do nothing with the reply and the Framework can’t make an assumption from the configuration phase that you are not going to handle this reply, we just have that exception at runtime. It can’t make that assumption because there is a message channel before that handle(), so you may send a message with replyChannel header from some other flow and so on. But! Since this is your code and you fully control it you may have an assumption that nobody is going to expect a reply from there and it would be better to stop streaming from this point. For this purpose it would be better to use one-way MessageHandler - based handle() variant or just return null instead of payload. You also may use channel(“nullChannel”) to stop streaming.