Channel.Close can hang when there is an unconsumed message about amqp HOT 2 CLOSED

It's best that this kind of retry/recovery/anticipation logic is not included in the library. The simple solution is to range over the consumer channel until the channel is closed.

With a buffered consumer chan, you would only be able to buffer a finite number of inflight content messages before the same behavior happens.

With closing the chan on Channel.Close, the only option is to drop the messages that are in-flight. If the connection is kept open and the consumer did not use autoAck, then a Nack should be sent back to indicate we've dropped the message and it should be redelivered to a different channel. If you don't do this, then the broker will only redistribute that message when the Connection is closed.

I don't think this library is the place to put that choice, that is very much up to the consumer to choose.

Instead, I feel it's much easier to understand the failure modes to have the constraint to always be receiving on consumer and notify chans until they are closed:

go func() {
  for msg := range consumerChan {
    if err := handler(msg); err != nil {
      msg.Nack()
    } else {
      msg.Ack()
    }
  }
}()

The alternative is when you are finished with your work and would like to exit your worker goroutine, call Channel.Cancel but still wait for the consumer chan to close, in this way all in-flight messages will be accounted for by the consumer.

from amqp.

You were right. I redesigned the whole close/shutdown process and now the channel is consumed until it is closed and closing is initiated the proper way. Thanks for your explanations.

from amqp.