Erik Olof Gunnar Andersson

There are some fundamental problems with how I implemented RPC that will make this a bit tricky to implement, but shouldn't be impossible. I'll need some time to think about...

> Thanks for both your responses, > > First I understood from the same article that transactions were quite slow. But It would fit my use case, so I will...

Thanks for the report. I'll see if I can figure out a work around on our side, and thanks for sharing your solution, at the very least this should help...

No current plans at least to support due to the pretty major differences in the protocols.

This is indeed a side effect of the current implementation when using no-ack set to True. I'll look into implementing some sort of back pressure functionality that could be used...

Are you using no_ack=True? If so you are probably hitting this. https://github.com/eandersson/amqpstorm/issues/34 Basically with no_ack set to true. RabbitMQ will keep sending messages over and over again, and because of...

Yea I think that would be worth implementing. When I wrote this originally I relied on heartbeats to keep the connection open, but since then the design has changed and...

> I seem to have the same problem, but `no_ack=False` (+ `prefetch_count=1`) didn't solve it :( My gunicorn workers sometimes silently reboot, and I can't find out why. I emulated...

The state is exposed on the connection level using the `is_blocked` property. e.g. ``` while connection.is_blocked: time.sleep(1) channel.publish(...) ``` I suspect that if you enable confirm_deliveries on the channel level...

I'll provide you with an example in a day or two.