Open Stack

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

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

I'm sorry for hijacking your question. :)

Cheers,
FF

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131217/521b760b/attachment.pgp>