Unexpected 204s and 404s when creating claims

[Malini Kamalambal]

===============
Scenario 1 of 2
===============

Steps to Repro:
Run the functional test test_claims.py.

Expected Result:
Response code of 201/204

Actual Result:
Post/Patch/Release claim APIs randomly get 404

===============
Scenario 2 of 2
===============

Post claim always returns 1 204, when there are a large number of message in the queue

Steps to Repro:
1. Post a large number of messages in the queue (~35K with Tsung)
2. Post claim against the queue

Expected Response:
The claim response will be a 201 , with a list of messages

Actual Response:
Claim returns a 204, despite having free messages in the queue

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/44536

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/44536
Committed: http://github.com/stackforge/marconi/commit/c1a564b4444a557cda037e57d7766b7b86661b4a
Submitter: Jenkins
Branch: master

commit c1a564b4444a557cda037e57d7766b7b86661b4a
Author: kgriffs <email address hidden>
Date: Fri Aug 30 14:47:24 2013 -0500

    fix: Claim can return 404

    This patch changes the way creating a claim behaves when the
    queue does not exist. Instead of returning 404, it returns
    204, meaning the claim was not able to find any messages to
    claim.

    This was done for two reasons:

    1. For eventually-consistent backends, a brand new queue may
    not appear to exist, so this new semantic allows the driver
    to just try to grab some messages without checking first
    whether the queue "exists".
    2. For backends like MongoDB that require an extra check to
    determine whether a queue exists, this removes an extra
    round trip to the DB in order to perform the operation.

    Note that the SQLite driver was updated in order to be
    consistent with the new behavior.

    Change-Id: Icde4ce493a76ef145e99300b67d8344d5092e38d
    Partial-Bug: #1218990

[Kurt Griffiths (kgriffs)]

Merged with bug #1219019 (the latter has been marked as "Invalid")

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/45299

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/45299
Committed: http://github.com/stackforge/marconi/commit/8d544d643dfa79634813052292bfeacf9a268be9
Submitter: Jenkins
Branch: master

commit 8d544d643dfa79634813052292bfeacf9a268be9
Author: kgriffs <email address hidden>
Date: Thu Sep 5 13:02:01 2013 -0500

    fix(storage.mongodb): Race condition when creating a claim

    This patch forces MessageController.claimed to always query the primary in
    order to resolve a race condition in ClaimController.create. The latter
    method tags a batch of messages with a claim ID, then immediately
    calles claimed() to get a list of messages that were actually updated.

    MessageController.claimed is also used by ClaimController.update, so that
    request will no longer read from secondaries either. This shouldn't put
    much more load on the primary, and may even be desired behavior in the case
    that a client creates a claim and immediately attempts to update it, in
    which case they could get a "not found" if the new claim hasn't propagated
    yet to the secondary being queried.

    Change-Id: I8b5cfee1cc6f185ebf53e98fad95a5fc30e021da
    Partial-Bug: #1218990

[Malini Kamalambal (malini-pk)]

verified fixed :)