On 11/06/14 10:19 +0100, Gordon Sim wrote:
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.
There are 2 main reasons that I don't believe are strong enough to change the way Marconi works right now: 1. Being able to support technologies that many deployments have already deployed. This will facilitate Marconi's adoption but it also brings in Marconi's scaling capabilities to those environments. 2. As Gordon mentioned, support for different performance characteristics.
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?
As it has been already mentioned in this thread - and older threads - there's no 1x1 mapping between Marconi's API and traditional brokers. I don't think it's even possible to put marconi on top of newer ones like Kafka. The reason is that this technologies rely on a streaming API which is quite different to Marconi's API. Flavio -- @flaper87 Flavio Percoco
pgpS1d8EJXiYB.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
