-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consuming without ACK #4
Comments
How are you trying to set The return of the Example: https://gist.github.com/pma/f912d799daeb894769a5083ab18062ad |
@arpunk ping |
Using |
@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 |
Is it possible to consume from a queue without ACK'ing?
I used to do this in
amqp
without problems but inwabbit
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 thehandle_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 thewabbit
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.
The text was updated successfully, but these errors were encountered: