<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 2, 2010, at 1:54 PM, Matthew Sackman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Actually, I think you'll see this bug if you just do: subscribe,<br>unsubscribe, recover. The second subscription should be unnecessary.<br></div></blockquote><div><br></div><div>Yes, you're right. </div><div><br></div><div><br></div><div><br></div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>Yes. There's probably an argument for saying that in the absence of a<br>valid consumer tag, the messages should be sent to the client as a<br>sequence of basic.get-oks, or at least a basic.deliver with a very<br>special ctag to indicate to the clients that they shouldn't be suprised<br>by these deliveries which are apparently appearing outside of the scope<br>of any subscription it knows about. This really seems to be a bug in the<br>spec rather than our implementation or the client.<br><br>At the very least, the basic.recover_ok should contain a new ctag (which<br>for symmetry suggests the client should be able to specify one in<br>basic.recover to mirror basic.consume and basic.consume_ok) which the<br>client can then use to identify these deliveries and route them<br>accordingly.<br></div></blockquote><div><br></div><div><div>At this point I should go and read the full specs to try to understand the reasons for this</div><div>design. However, I don't see the reason for redelivering messages to a consumer that</div><div>already said explicitly that it doesn't want to receive messages from that queue anymore.</div><div>Why don't just redeliver the messages to other possible subscribers after the subscription</div><div>cancel was received? Ok, maybe the consumer can subscribe again using the same ctag (the library</div><div>should allow to do so) or the server should understand the change of ctag, given that there</div><div>cannot be two consumers for the same queue on the same channel, right?</div><div><br></div><div>I just have a couple of weeks of experience with AMQP and RabbitMQ and I'm still</div><div>trying to figure out the architecture patters that I should follow for our design. One thing</div><div>that still results strange to me is that the recover operates only at a channel level and there</div><div>is no way to recover messages just for one queue.</div><div><br></div></div><blockquote type="cite"><div>I would recommend that you don't use recover without also setting<br>requeue=true, thus ensuring the messages are inserted back into the<br>queue and can hence be redelivered to any valid consumer again (at<br>which point the ctag will be set correctly). Hopefully you'll at<br>least get unsurprising behaviour! I will raise some bugs to cover the<br>issues uncovered - many thanks for the report.<br></div></blockquote><br></div><div>Yes! this solved my issue.</div><div><br></div>- Juan</body></html>