[rabbitmq-discuss] Making persistence simpler (Was: AMQP & Python Write-Up)

Sat Jan 17 13:10:51 GMT 2009

Hi,

I am reposting Jason's thoughts on simplifying AMQP persistence to the
list, with his permission.

alexis

---------- Forwarded message ----------
From: Jason J. W. Williams <jasonjwwilliams at gmail.com>
Date: Thu, Jan 15, 2009 at 8:56 PM
Subject: Re: [rabbitmq-discuss] AMQP & Python Write-Up
To: Alexis Richardson <alexis.richardson at gmail.com>

Hi Alexis,

My thinking on it is that the publisher should be able to be as "dumb"
as possible. This seems to be a tenet of AMQP from my reading, based
on the fact that it doesn't know where the message is going.

In the way we're designing uses for the queues, the consumers are the
ones that know if they need the messages to be persistent, or rather
know the value of the message. Largely because they have the details
on what they're doing with the message.

To that end, requiring every publisher to mark a message consistent,
means one accidentally may not be coded that way, and thereby will
override the consumer's need for the message to be persistent.

It seems to me in that regard, it makes more sense to make persistence
an attribute of the exchange and the queue (as durable is).

Fewer moving parts to keep track of, and the publishers can be
simple-minded minions. ;-)

Just my very uninformed opinion.

-J

On Thu, Jan 15, 2009 at 2:15 AM, Alexis Richardson
> On Thu, Jan 15, 2009 at 12:58 AM, Jason J. W. Williams
> <jasonjwwilliams at gmail.com> wrote:
>> Barry & Gordon,
>>
>> Entry has been updated with the correct no_ack explanation. Regarding
>> the None return on "no message waiting" from basic_get(), I chose to
>> explain that in words, rather than trap it out in the code to maintain
>> clarity.
>>
>> http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/
>>
>> Thank you very much for your help.
>>
>> -J
>>
>> On Wed, Jan 14, 2009 at 5:28 PM, Barry Pederson <bp at barryp.org> wrote:
>>> Gordon Sim wrote:
>>>>
>>>> Jason J. W. Williams wrote:
>>>>>
>>>>> I've written up a quick start on the basics of AMQP and using it in
>>>>> Python, that is the kind of document I wished I'd been able to find in
>>>>> one place: http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/
>>>>>
>>>>> It's probably laced with errors, and I'd appreciate any
>>>>> feedback/corrections.
>>>>
>>>> Nice article!
>>>>
>>>> I am not that familiar with py-amqplib but the no_ack argument to
>>>> basic_consume/basic_get is defined in the AMQP spec to mean that the server
>>>> should not expect an ack and should discard the message on delivery. I.e.
>>>> its an unreliable mode of delivery[1] rather than a signal to the client
>>>> library to automatically acknowledge on receiving a message.
>>>
>>> I just read the article too, very nice.
>>>
>>> Gordon's right about the no_ack flag, this sentence:
>>>
>>>  If you set the no_ack argument to true, then py-amqplib will
>>>  automatically send the acknowledgement immediately for you.
>>>
>>> should probably instead say something like what Gordon mentions above - it's
>>> the broker that acts differently based on that flag, not the client library.
>>>
>>> The only other thing I noticed was this section:
>>>
>>> ----
>>> Now, there's two methods of getting messages out of the queue. The first is
>>> to call chan.basic_get() to pull the next message off the queue:
>>>
>>>   1. msg = chan.basic_get("po_box")
>>>   2. print msg.body()
>>>   3. chan.basic_ack(msg.delivery_tag)
>>> ----
>>>
>>> If there isn't a message waiting in the queue when line 1 executes, then msg
>>> is set to None and line 2 will die since None does not have a "body"
>>> attribute.  Also, body is not a function to call, it's just a string, so
>>> this would be more appropriate:
>>>
>>>    msg = chan.basic_get("po_box")
>>>    if msg is not None:
>>>        print msg.body
>>>        chan.basic_ack(msg.delivery_tag)
>>>
>>> ================
>>>
>>>        Barry
>>>
>>>
>>>
>>
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
>