On 06/10/2014 05:27 PM, Kurt Griffiths wrote:
I think the crux of the issue is that Marconi follows the REST
architectural style. As such, the client must track the state of where it
is in the queue it is consuming (to keep the server stateless). So, it
must be given some kind of marker, allowing it to page through messages in
the queue.
Isn't this true both for task distribution and feed semantics?
[...]
To my knowledge, this API can’t be mapped directly to AMQP.
I believe you are right, you could not map the HTTP based interface
defined for Marconi onto standard AMQP. As well as the explicit paging
through the queue you mention above, the concepts of claims and direct
deletion of messages are not exposed through AMQP[1].
AMQP was designed as an alternative interface into a messaging service,
one tailored for asynchronous behaviour. It isn't intended as a direct
interface to message storage.
Perhaps there are other types of brokers that can do it?
There are certainly brokers that support a RESTful HTTP based
interface[2] alongside other protocols. I don't know of any standard
protocol designed for controlling message storage however.
--Gordon.
[1] You could use a filter (aka a selector) to retrieve/dequeue a
specific message by id or some other property. You could also define
behaviour where an acquired message gets automatically released by the
server after a configurable time. However, in my view, even with such
extensions AMQP would still not be an ideal interface for message
*storage* as opposed to message transfer between two processes.
[2] http://activemq.apache.org/rest.html, http://hornetq.jboss.org/rest
and I'm sure there are others.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
