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 discussionI 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.
* 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 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.
* 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 -- @flaper87 Flavio Percoco
pgpBLyKwg2WLL.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
