[openstack-dev] [oslo]: implementing olso.messaging over amqp 1.0
flavio at redhat.com
Tue Dec 17 14:57:22 UTC 2013
On 17/12/13 14:22 +0000, Gordon Sim wrote:
>On 12/17/2013 01:53 PM, Flavio Percoco wrote:
>>On 16/12/13 10:37 +0000, Gordon Sim wrote:
>>>On 12/12/2013 02:14 PM, Flavio Percoco wrote:
>>>>I've a draft in my head of how the amqp 1.0 driver could be
>>>>implemented and how to map the current expectations of the messaging
>>>>layer to the new protocol.
>>>>I think a separate thread to discuss this mapping is worth it. There
>>>>are some critical areas that definitely need more discussion
>>>I have also been looking at this, and trying to write up a simple
>>>design notes. Some of the questions that occurred to me while doing so
>>>* Use one link for all sends, with 'to' field set, or use a link for
>>I like this proposal. It keeps messages atomic and isolated from the
>>rest of the environment. The only I can think OTO is: What happens if
>>the node that the reply should go to dies before the reply is sent?
>>Is this something we should be worrying about? I mean, if the node
>>that was waiting for the response dies, I think we'd have bigger
>>problems than just a 'missed response' :D. However, this doesn't mean
>>we couldn't take care of that.
>I'm afraid I'm not following you here. To clarify the original point,
>in AMQP 1.0 all messages are sent over a sending link (this is like a
>subscription, but for senders). You can also set an address
>per-message. However my view is that using a link per target is more
>interoperable at present. The spec doesn't really require the routing
>of messages by 'to' field and consequently not all implementations
>The point you are making seems to be around reliability(?). I would
>like to see some definitive statement about expectations in that
>regard for the API users and for transport implementers, but I think
>its a separate issue from whether or not to use a single link.
>(Perhaps the term 'link' is overloaded here, causing the confusion. In
>AMQP 1.0 a link is something like a subscription, but its a symmetric
>concept so also covers sending of messages).
I'm sorry, it was indeed a bit confusing. What I'm referring to, which
I think is related to the above issue, is that the 'reply-to' field
needs to be sent either way. My question was indeed more related to
reliability and as you mentioned it needs to be clarified a bit
I'm sorry for hijacking your question. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: not available
More information about the OpenStack-dev