<br><br><div class="gmail_quote">On Tue, Feb 19, 2013 at 12:25 PM, Kurt Griffiths <span dir="ltr"><<a href="mailto:kurt.griffiths@rackspace.com" target="_blank">kurt.griffiths@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> It seems like the resources being changed are the messages...<br>
<br>
That is correct. The client is applying a bulk PATCH operation to multiple messages. There's an implicit "claimed=false" query param that filters the messages to which the PATCH is applied.<br>
<div class="im"><br>
> Isn't it more semantically correct to POST a claim request, and get a claim ID and list of messages back?<br>
<br>
</div>Not necessarily. json-patch [1] allows for adding to an existing resource:<br>
<br>
Because this operation is designed to add to existing objects and<br>
arrays, its target location will often not exist.<br>
<br>
Also, from RFC 5789 [2]:<br>
<br>
With PATCH, however, the enclosed entity contains a set<br>
of instructions describing how a resource currently residing on the<br>
origin server should be modified to produce a new version.<br>
<br>
That being said, the server is generating the ID for the claim object that is being added to each resource, and PATCH isn't really defined to apply to more than one resource. The implicit "claimed=false" filter is also a bit odd. I found this, again from RFC 5789:<br>
<br>
A comparison to POST is even more difficult, because POST is used in<br>
widely varying ways and can encompass PUT and PATCH-like operations<br>
if the server chooses. If the operation does not modify the resource<br>
identified by the Request-URI in a predictable way, POST should be<br>
considered instead of PATCH or PUT.<br>
<br>
Given the not-so-predictable way PATCH is being used to claim messages in the current API draft, I'm inclined to agree that the approach to claiming messages should be changed.<br>
<br>
As an alternative to using PATCH, the API could accept a POST to a "claims" collection, e.g.:<br>
<br>
POST /v1/12345/queues/foo-bar/claims<br>
<br>
{ "ttl": 30 }<br>
<br>
And the server would return the claim ID and a list of n messages associated with that claim, e.g.:<br>
<br>
{<br>
"claim": {<br>
"id": "a28ee94e-6cb4-11e2-b4d5-7703267a7926",<br>
"ttl": 30,<br>
"age": 0<br>
}<br>
<br>
"messages": [<br>
...<br>
]<br>
}<br></blockquote><div><br></div><div>That's basically what I was thinking.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In this approach, a client could renew a claim by PATCHing its age to 0, or using PUT to overwrite the entire claim resource. A client could also DELETE a claim if it has been asked to shut down or has encountered a fatal error, to give a different client a chance to pick up the claimed messages. Furthermore, DELETEing a message could still take a claim_id parameter to ensure that a client can only remove a message that it has previously claimed.<br>
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
One downside of this approach is that clients can't renew claims for individual messages; a renewal of a claim would renew it for the entire batch. So, if a client failed to process a single message but wanted to do the rest of the batch, it wouldn't have a way to release that one message for another worker to pick up. On the other hand, the client could simply DELETE its current claim and create a new one to get a fresh batch of messages to work on, effectively rebalancing the messages in the first claim across workers.<br>
<br>
> We've had good luck building the v2 API for ceilometer using WSME.<br>
<br>
Thanks for the tip; I'll check it out. However, Marconi is highly sensitive to latency, so WSME would have to be pretty darn fast for us to use it.<br></blockquote><div><br></div><div>Makes sense. In general, I would rather we contribute back and improve it than build yet another serialization system, but maybe the requirements here are sufficiently different that they warrant a new tool.</div>
<div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
@kgriffs<br>
<br>
<br>
[1]: <a href="http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10#section-4.1" target="_blank">http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10#section-4.1</a><br>
[2]: <a href="http://tools.ietf.org/html/rfc5789#section-2.2" target="_blank">http://tools.ietf.org/html/rfc5789#section-2.2</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br>