<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">(30/07/13 16:30), Tom Anderson wrote:<br>
</div>
<blockquote cite="mid:51F7DBFE.1020306@timgroup.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 29/07/13 17:51, Ceri Storey wrote:<br>
</div>
<blockquote cite="mid:51F69D9D.9000704@lshift.net" type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
<div class="moz-cite-prefix">(29/07/13 17:25), Tom Anderson
wrote:<br>
</div>
<blockquote cite="mid:51F69780.6080602@timgroup.com" type="cite">
<div class="moz-cite-prefix">On 29/07/13 13:40, Matthias
Radestock wrote:<br>
</div>
<blockquote cite="mid:51F662A6.3060006@rabbitmq.com"
type="cite">...<br>
</blockquote>
<br>
Aha. I didn't realise, that, thanks.<br>
<br>
What i'm looking for is a way to get some sort of feedback at
the sender when a message has been acknowledged by the
consumer. Given that transient messages are confirmed as soon
as the message has reached the queue, and persistent messages
are confirmed as soon as they are written to disk, am i right
in concluding that there is no way to do this with confirms?
Is there any other mechanism in RabbitMQ that might let me do
this?<br>
<br>
My real goal here is to write a test for an application of
ours, to assert that it is only acknowledging messages after
it has successfully processed them, and not immediately on
receipt. If anyone has any thoughts on how i might be able to
do that, i would be very excited to hear them!<br>
</blockquote>
For your test, I'd be very tempted to provide an adapter which
enforces the guarantees you want to make. Then you can have
tests that:<br>
<ul>
<li>For the happy path, asserts that no more messages exist on
the expected (ie: that a <tt>basic.get</tt> will return no
messages)<br>
</li>
<li>For the failure path, asserts that the sent message is
available to other consumers once your adapter has properly
failed and shut down. <br>
</li>
</ul>
<p>Granted, the latter does assume that you can shut down the
adapter reasonably easily. <br>
</p>
</blockquote>
<br>
Apologies if i'm being thick, but what do you mean by "adapter"?
Do you mean code that sits between the application code and the
AMQP library? Or code that the test can use to take a grip on the
application code? Or something else?<br>
</blockquote>
Yes, sorry, that's it, so it's an interface to external
infrastructure (in this case Rabbit), that presents itself in terms
of something relevant to your application. So in my case, I tell it
what what kinds of job I want to receive, and it would call back to
another object when there is a job to be done. It's a term pulled
from Alistair Cockburn's <a
href="http://alistair.cockburn.us/Hexagonal+architecture">Hexagonal
Architecture</a>, FWIW.<br>
</body>
</html>