Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140611/55429dd3/attachment.pgp>