pma
Consuming without ACK
Is it possible to consume from a queue without ACK'ing?
I used to do this in amqp without problems but in wabbit I haven't been able to do so. Can you point me to the place to set up such flag? I tried on the producer options but it didn't work.
What I tried was to set no_ack: true in the handle_channel_opened/2 callback but then I see my consumers go up and down in the RabbitMQ admin panel and I see tons of enqueued messages. There are messages that are being received by the wabbit consumer and I don't see any errors or disconnections. Any ideas?
I'm using the master branch, Erlang/OTP 19.2 and Elixir 1.4.0-rc.1.
How are you trying to set no_ack: true?
The return of the handle_channel_opened/2 callback is {:ok, queue, new_state, consume_options}, where consume_options is a Keyword list that can include no_ack: true. These options are just passed to the equivalent of AMQP.Basic.consume.
Example: https://gist.github.com/pma/f912d799daeb894769a5083ab18062ad
Using no_ack: true in the options has no effect: I see no connected consumers in RabbitMQ and I see a lot of stalled messages, but I also see that data is arriving at the consumer.
@arpunk I have tried to reproduce your issue with https://github.com/pma/wabbit_test.
When running, I see one Connection and two Channels, as expected. Both channels show a message flow and there is one consumer connected to one of the channels.
I don't see the same behaviour, where messages are stalled. Instead, I see messages being published, confirmed and delivered. Maybe we are doing something different in the client code?
I do however see an issue with using no_ack: true. With this option, the Source, which is a RabbitMQ consumer and a GenStage producer, has no flow control. This means it can receive message from the broker faster than it's subscribed GenStage consumer can handle and it will start discarding messages. I think we can address this by calling Basic.cancel when demand is 0 and reissuing Basic.consume once demand is greater than 0.
Sorry for the delay.
I am going to try to get no_ack: true to work in the afternoon. I haven't tried it further because we are ACK'ing in production so currently it is not an issue for me.