Open Stack

On 10/06/14 18:12 +0000, Janczuk, Tomasz wrote:
>I the last few days I attempted to implement a RabbitMQ (AMQP 0.9) storage driver for Marconi. These are the take-aways from this experiment. High level, it showed that current Marconi APIs *cannot* be mapped onto the AMQP 0.9 abstractions. In fact, currently it is not even possible to support a subset of functionality that would allow both message publication and consumption.

First and foremost, thank you!

This is a great summary. I've been willing to do the same for quite
some time and never got to it.

Based on your findings, I'm making some questions that are not related
to supporting AMQP drivers but having a better and reasonable API.

>
>  1.  Marconi exposes HTTP APIs that allow messages to be listed without consuming them. This API cannot be implemented on top of AMQP 0.9 which implements a strict queueing semantics.

I believe this is quite an important endpoint for Marconi. It's not
about listing messages but getting batch of messages. Wether it is
through claims or not doesn't really matter. What matters is giving
the user the opportunity to get a set of messages, do some work and
decide what to do with those messages afterwards.

>
>  2.  Marconi exposes HTTP APIs that allow random access to messages by ID. This API cannot be implemented on top of AMQP 0.9 which does not allow random access to messages, and the message ID concept is not present in the model.

We recently discussed the faith of this endpoint[0]. We can followup
there or later on when we start discussing v2.

>  3.  Marconi exposes HTTP APIs that allow queues to be created, deleted, and listed. Queue creation and deletion can be implemented with AMQP 0.9, but listing queues is not possible with AMQP. However, listing queues can be implemented by accessing RabbitMQ management plugin over proprietary HTTP APIs that Rabbit exposes.

We were really close to get rid of queues but we decided to keep them
around at the summit. One of the reasons to keep queues is their
metadata - rarely used but still useful for some use cases.

Monitoring and UIs may be another interesting use case to keep queues
around as a first citizen resource.

I must admit that keeping queues around still bugs me a bit but I'll
get over it.

>  4.  Marconi message publishing APIs return server-assigned message IDs. Message IDs are absent from the AMQP 0.9 model and so the result of message publication cannot provide them.

I think this is related to whatever we decide for #2

>
>  5.  Marconi message consumption API creates a “claim ID” for a set of consumed messages, up to a limit. In the AMQP 0.9 model (as well as SQS and Azure Queues), “claim ID” maps onto the concept of “delivery tag” which has a 1-1 relationship with a message. Since there is no way to represent the 1-N mapping between claimID and messages in the AMQP 0.9 model, it effectively restrict consumption of messages to one per claimID. This in turn prevents batch consumption benefits.
>
>  6.  Marconi message consumption acknowledgment requires both claimID and messageID to be provided. MessageID concept is missing in AMQP 0.9. In order to implement this API, assuming the artificial 1-1 restriction of claim-message mapping from #5 above, this API could be implemented by requiring that messageID === claimID. This is really a workaround.
>

These 2 points represent quite a change in the way Marconi works and a
trade-off in terms of batch consumption (as you mentioned). I believe
we can have support for both things. For example, claimID+suffix where
suffix point to a specific claimed messages.

I don't want to start an extended discussion about this here but lets
keep in mind that we may be able to support both. I personally think
Marconi's claim's are reasonable as they are, which means I currently
like them better than SQS's.

>  7.  RabbitMQ message acknowledgment MUST be sent over the same AMQP channel instance on which the message was originally received. This requires that the two Marconi HTTP calls that receive and acknowledge a message are affinitized to the same Marconi backend. It either substantially complicates driver implementation (server-side reverse proxing of requests) or adds new requirements onto the Marconi deployment (server affinity through load balancing).
>

Nothing to do here. I guess a combination with a persistent-transport
protocol would help but we don't want to make the store driver depend
on the transport.


>  8.  Currently Marconi does not support an HTTP API that allows a message to be consumed with immediate acknowledgement (such API is in the pipeline however). Despite the fact that such API would not even support the at-least-once guarantee, combined with the restriction from #7 it means that there is simply *no way* currently for a RabbitMQ based driver to implement any form of message consumption using today’s HTTP API.

>If Marconi aspires to support a range of implementation choices for the HTTP APIs it prescribes, the HTTP APIs will likely need to be re-factored and simplified. Key issues are related to the APIs that allow messages to be looked up without consuming them, the explicit modeling of message IDs (unnecessary in systems with strict queuing semantics), and the acknowledgment (claim) model that is different from most acknowledgments models out there (SQS, Azure Queues, AMQP).
>
>I believe Marconi would benefit from a small set of core HTTP APIs that reflect a strict messaging semantics, providing a scenario parity with SQS or Azure Storage Queues.
>

Simplifying the API is definitely something the team wants to do. v2.0
of the API seems a good target for this simplification. Lets iterate
over the existing endpoints, write everything down on an etherpad and
evaluate everything.

One thing I do want to say is that despite Marconi being akin to SQS
and Azure Queues, it doesn't aim to be *just* like them. Lets learn
from their experiences and do the changes that we consider best for
the final user.

Flavio

[0] https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg25385.html


-- 
@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/7c95c18f/attachment.pgp>