<font face="arial" size="2"><p style="margin:0;padding:0;">Yes, I'll take up this issue with the ruby-amqp groups.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">I'm asking questions and carefully reporting the behavior I've observed. I'm new to these tools - RabbitMQ server, and the ruby amqp gem. These tools have been around for a while, and the platforms I'm using - RabbitMQ and Ruby and Ubuntu, RabbitMQ and Ruby and Mac OS - are used by many, many developers. It would be -arrogant- and foolish of me to assume that I've immediately stumbled upon a bug in code that I expect has been well-exercised out there in the world. So I'm trying to determine if I'm traversing less-used code paths, using new features, implementing an unusual use case or pattern, misunderstanding how ACKs are supposed to work, or misunderstanding how client-side state is propagated.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">-larry</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">-----Original Message-----<br />From: "Matthias Radestock" <matthias@rabbitmq.com><br />Sent: Thursday, November 8, 2012 3:42pm<br />To: "Discussions about RabbitMQ" <rabbitmq-discuss@lists.rabbitmq.com><br />Cc: larry.edelstein@therealreal.com<br />Subject: Re: [rabbitmq-discuss] redelivery after ACK<br /><br /></p>
<div id="SafeStyles1352421543">
<p style="margin:0;padding:0;">Larry,<br /><br />On 08/11/12 22:18, larry.edelstein@therealreal.com wrote:<br />> When I run a capture with Wireshark and consume/ack a few messages, I<br />> see the expected traffic, but no acks.<br />><br />> However: when I set channel.prefetch(1), now I see the acks. If I kill<br />> and restart the consumer, delivery begins with the first un-ack'd<br />> message, as I'd expect.<br />><br />> In fact, if I set channel.prefetch(..) to n, and kill/restart the<br />> consumer after n+1 messages have been received and ack'd, delivery<br />> resumes with the first un-ack'd message.<br />><br />> And if I issue a queue.unsubscribe, then kill and restart, delivery<br />> resumes with un-ack'd messages.<br />><br />> Have I misunderstood the way RabbitMQ and/or the gem are supposed to<br />> behave? I really thought an ack was an ack.<br /><br />It's not clear what in the above you find surprising, except for the <br />first observation. If your app is sending an ack but that doesn't show <br />up on the wire then clearly there is a problem with either the app, or <br />the client library, or the app's use of the client library.<br /><br />I suggest you post on http://groups.google.com/group/ruby-amqp or <br />perhaps file an issue at https://github.com/ruby-amqp/amqp/issues<br /><br />Regards,<br /><br />Matthias.</p>
</div></font>