[rabbitmq-discuss] Trouble with confirms

[Tom Anderson]

On 30/07/13 17:05, Ceri Storey wrote:
> (30/07/13 16:30), Tom Anderson wrote:
>> On 29/07/13 17:51, Ceri Storey wrote:
>>> (29/07/13 17:25), Tom Anderson wrote:
>>>> On 29/07/13 13:40, Matthias Radestock wrote:
>>>>> ...
>>>>
>>>> Aha. I didn't realise, that, thanks.
>>>>
>>>> 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?
>>>>
>>>> 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!
>>> 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:
>>>
>>>   * For the happy path, asserts that no more messages exist on the
>>>     expected (ie: that a basic.get will return no messages)
>>>   * For the failure path, asserts that the sent message is available
>>>     to other consumers once your adapter has properly failed and
>>>     shut down.
>>>
>>> Granted, the latter does assume that you can shut down the adapter 
>>> reasonably easily.
>>>
>>
>> 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?
> 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 Hexagonal Architecture 
> <http://alistair.cockburn.us/Hexagonal+architecture>, FWIW.

Maybe also similar to Nat Pryce's 'simplicator' then:

http://www.natpryce.com/articles/000785.html

The thing is, what i really want to test, because it's the thing i have 
most uncertainty about, is my usage of the RabbitMQ API. That would be 
in the adaptor. So, introducing that adaptor would let me write tests 
around the logic inside the application, but they would be rather 
vacuous, and they would leave the scary bit untested.

It is probably still worth driving a plane of fracture through the 
system above the RabbitMQ API and unit-testing that, though. I can then 
at least be confident that bugs are boxed into the API-using code, and 
then write the best end-to-end integration test i can manage, even if 
it's not rock solid.

tom

-- 

Tom Anderson | Developer | +44 20 7826 4312 | timgroup.com 
<http://timgroup.com/>

STATEMENT OF CONFIDENTIALITY: The information contained in this 
electronic message and any attachments to this message are intended for 
the exclusive use of the addressee(s) and may contain confidential or 
privileged information. If you are not the intended recipient, please 
notify Tom Anderson at TIM Group at tom.anderson at timgroup.com and 
destroy all copies of this message and any attachments.

TIM Group is the trading name for YouDevise Limited. YouDevise Limited 
is registered in England, No. 3331176. Registered office: 3 Copthall 
Avenue, London, EC2R 7BH.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130731/dfa92dfb/attachment.htm>