Open Stack

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
>> are:
>>
>> * Use one link for all sends, with 'to' field set, or use a link for
>> each target?
>
> 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 support it.

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).

>> * How to handle calls to one of a group of servers?
>
> Could you elaborate more what issues you see around this?

In the 0-9-1 and 0-10 drivers, the pattern here is implemented by a 
shared subscription queue.

AMQP 1.0 doesn't define any mechanism to create a shared queue or a 
shared subscription. However most of the 1.0 implementations do allow 
queues to be created on demand. In the notes I wrote, I suggested using 
configurable prefixes for the addresses used, in order to accommodate a 
variety of implementations.

>> * Use a distinct response address per request, or allow an address to
>> be shared by multiple requests in conjunction with correlation id on
>> responses?
>
> 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
> later.

Yes, I lean towards the latter option also. I'm actually not sure it is 
any more error prone either.

>> * Support both intermediated and direct communication? For all patterns?
>
> Besides fanout, I'd say yes. We need to support intermediated and
> direct communication.
>
>> 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 extensions.
>>
>> 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.
>
> Cheers,
> FF
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>