Open Stack

On 10/09/2012 01:07 PM, Day, Phil wrote:

> What do people think about adding a version number to the notification
> systems, so that consumers of notification messages are protected to
> some extent from changes in the message contents ?
>
> For example, would it be enough to add a version number to the messages
> – or should we have the version number as part of the topic itself (so
> that the notification system can provide both a 1.0 and 1.1 feed), etc ?

Putting a version number in the messages is easy, and should work fine. 
  Of course it only really helps if someone writes clients that can deal 
with multiple versions, or at least give helpful error messages when 
they get an unexpected version.

I think using separate topics for each version would be inefficient and 
error-prone.

Inefficient because you'd have to send out multiples of each message, 
some of which would probably never be read.  Obviously, if you're 
sending out N copies of each message then you expect only 1/N the queue 
performance.  Worse, if you're sending out N copies of each message but 
only 1 of them is being consumed, your queue server is using a lot more 
memory than it needs to, to hold onto old messages that nobody needs. 
(If you properly configure a high-water mark or timeout, then the old 
messages will eventually be thrown away.  If you don't, then your queue 
server will eventually consume way too much memory and start swapping, 
your cloud will break, and someone will get paged at 2 a.m.)

Error-prone because someone would end up reusing the notification queue 
code for less idempotent/safe uses of queues, like internal API calls. 
And then client A would pick up the message from topic_v1, and client B 
would pick up the same message from topic_v2, and they'd both perform 
the same API operation, resulting in wasted resources in the best case 
and data corruption in the worst case.

-- 
David Ripton   Red Hat   dripton at redhat.com