Consumer stop getting messages about amqp HOT 9 CLOSED

Added the information to README. Thanks!

from amqp.

@bradleyd Is the client connected directly to the broker? Or through something like haproxy? When using haproxy you can use the heartbeat: n option in AMQP.Connection.open (n seconds must be less than haproxy connection timeout).

from amqp.

It is connected through aws load balancer. Heartbeat is set to 60

from amqp.

Actually that is false. I was thinking of remote connection. This is connection on same host over 127.0.0.1

from amqp.

@bradleyd That excludes the possibility of a load-balancer closing the backend connection...
Looking at the queue status in the RabbitMQ management console, do you see the messages being acked, or are they accumulating in the queue (in either ready or unacked state)?

When looking at the queue detail in the management console, does it still list consumers?

from amqp.

Thanks for trying to help @pma.

The messages are accumulating in ready. The consumer is also listed from console. I sniffed the local consumer port hoping to catch messages, but all I see is what looks like the heartbeat being sent back and forth

from amqp.

@bradleyd I'm also facing the same issue. Did you get any further insight on this?

from amqp.

I've been through this and realize that I wasn't handling message properly. In the README example that try/rescue may no catch unexpected errors avoiding you to call ack/reject. Consumers needs to send acknowledges (aka.. ack/reject) to the broker so it can send more messages.

No matter what happens handling the message you will ack or reject and the broker will send you more messages:

def handle_info({:basic_deliver, payload, %{delivery_tag: tag, redelivered: redelivered}}, [chan, opts] = state) do
  spawn fn ->
    handler = @opts[:handler]
    with {:ok, data} <- Poison.decode(payload),
         {:ok, _} = handler.handle(data) do
         ack(chan, tag)
    else
       _ -> reject(chan, tag, requeue: not redelivered)
    end
  end
  {:noreply, state}
 end

May it can help someone

from amqp.

Yeah, we had similar issues. If the handler silently fails or is stuck, ack or nack won't be sent. Then once the number gets more than prefetch_count, consumer stops receiving any messages.

@bradleyd @trenpixster can this be a cause of the issue you experienced? Or you are seeing something else?

Since it can be a typical pitfall, I am planning to write something about it in README.

from amqp.