[openstack-dev] [marconi] Reconsidering the unified API model
Gordon Sim
gsim at redhat.com
Wed Jun 11 09:19:30 UTC 2014
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.
More information about the OpenStack-dev
mailing list