[openstack-dev] [oslo]: implementing olso.messaging over amqp 1.0
flavio at redhat.com
Tue Dec 17 13:53:16 UTC 2013
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.
>* How to handle calls to one of a group of servers?
Could you elaborate more what issues you see around this?
>* Use a distinct response address per request, or allow an address to
>be shared by multiple requests in conjunction with correlation id on
mmh, this is an interesting one. Using a distinct address for
responses will make the implementation less error prone. However, I
don't really think we need to have different addresses since there's
already a way to distinguish multiple requests. So, I'd prefer the
>* Support both intermediated and direct communication? For all patterns?
Besides fanout, I'd say yes. We need to support intermediated and
>The aim in my view should be to have the driver support as many
>alternatives in deployment as possible without overcomplicating
>things, distorting the mapping or introducing server specific
>I have some notes to share if anyone is interested. I can send them to
>this list or put them upon the wiki or an etherpad or something.
I think this questions are worth raising - thanks for that - and I
agree with you about not overcomplicating things. I think we could
start working something out and then we'll face different issues that
we'll need to discuss further on this list.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: not available
More information about the OpenStack-dev