Message loss after a netweork disconnect

[rasadoll]

Another observation:
It works fine when acknowledge="auto" on the container.

I have to admit that we enabled auto-ack (acknowledge="none") when we switched to spring-amqp. So my previous test with pure rabbitmq api was based on programmatic acking the message. I would try that to verify if it is a rabbitmq issue.

Thanks,

[Gary Russell]

I was able to reproduce your issue with a windows client (in a VM - disabling the VM's network interface is the equivalent of pulling the cable, and I see the connection broken in the log).

There was no activity at all on the client for the lost message after the connection was restored.

I have to believe this is an artifact of auto-ack - if you think about it - the broker sends the message after the interruption; auto-acks it; and THEN is informed by the network that the connection was broken - too late to recover the message.

This explains why acknowledge="auto" and/or using heartbeats solves the issue, but I suspect that heartbeats may not suffice for very brief network outages.


So, the bottom line is I don't believe it's a spring-amqp OR RabbitMQ issue - it's just an artifact of the way auto-ack works. If you disagree, I suggest you raise it on the RabbitMQ mailing list. If you do, please post a link here.

[Gary Russell]

Is spring-amqp 1.1.2 fully compatible with rabbitmq 3.0?

I just started testing (for this thread, and with spring-amqp 1.1.3 - the current release) and haven't found any problems yet. I do know that immediate mode and x-federated exchanges are no longer supported so we need to remove (deprecate) support for those from spring-amqp too. But, I am not aware of anything that should prevent s-a being used with Rabbit 3.0.0 (as long as you are not using immediate or x-federated exchanges).

[rasadoll]

Thank you very much Gary,
You are absolutely right about the auto-ack behavior. I had the impression that auto-ack is simply an explicit ack done by the client just before calling the client code, which I was wrong, as it is part of the amqp protocol and maintained by the server.

I also found the following link which answers my questions:
https://groups.google.com/forum/?fro...ss/SapkdSr6MK0

For our particular case, I would change the ack mode on the container to "manual" and ack the message before our processing business logic as we wanted to avoid re-processing of a message in case of consumer or broker crash.

Thanks