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.
Last edited by Gary Russell; Nov 22nd, 2012 at 08:30 PM.
Gary P. Russell
Spring Integration Team
SpringSource, a division of VMware