AMQP 1.0 driver ignores message send failures

[Ken Giusti]

When an application sends a message via the driver, the message is merely queued for processing by the event loop, and the send() method returns immediately. There is no feedback provided as to whether the message was actually sent.

For the RPC call pattern, getting the status of the send operation isn't mandatory, as the sender will block for a response (and fail if the response does not arrive). But for notifications, this behavior is bad for two reasons: 1) the send may fail, and the caller is not aware of the failure, and 2) there is no way to backpressure senders using credit.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Change abandoned by Flavio Percoco (<email address hidden>) on branch: master
Review: https://review.openstack.org/126065

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/126065
Committed: https://git.openstack.org/cgit/openstack/oslo.messaging/commit/?id=c127594de69c1443993ddff171738d8d7ad058aa
Submitter: Jenkins
Branch: master

commit c127594de69c1443993ddff171738d8d7ad058aa
Author: Kenneth Giusti <email address hidden>
Date: Mon Jun 1 10:24:45 2015 -0400

    Provide better detection of failures during message send

    This change causes the message sender to block until the messaging
    infrastructure (e.g. the broker) assumes ownership of the message (or
    fails to accept it). If the message is accepted, then the sender will
    either pend for a response (in the case of RPC), or simply return (in
    the case of notification). If the message is rejected by the
    messaging infrastructure a MessagingException will be raised at the
    sender.

    Change-Id: I3f4a1ed1c17e18f6d629f16e6b5c99de45b083d6
    Closes-Bug: #1377228