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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
