On 06/10/2014 09:59 PM, Mark McLoughlin wrote:
Now why is there a desire to implement these requirements using traditional message brokers?
I would speculate that any desire to utilise a message broker as opposed to a database would be to achieve different performance characteristics for the service.
E.g. a message broker might be optimised for high throughput and low latency, a database for handling very large queues and random access to messages.
However if the interface through which the service is used requires random access to messages and polling then any perceived benefits of using a broker may not be realised anyway.
And what Marconi API semantics are impossible to implement using traditional message brokers? Either those semantics are fundamental requirements for this API, or the requirement to have support for traditional message brokers is the fundamental requirement. We can't have it both ways.
I suspect is is a question of understanding the expected performance metrics, the impact on those that aspects of the API design may have, and whether those aspects are intrinsic to the semantic requirements.
Is there an explicit list of requirements for Marconi anywhere? I've seen the use cases, which are useful. What would be the expected message rates and latencies for these patterns?
--Gordon. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
