qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject What on_sendable() means
Date Thu, 27 Oct 2016 15:43:23 GMT
This issue comes up a lot and I just wrote an answer about it so
thought I'd share it:

There are two reasons a sender can be "blocked": 
1. No AMQP credit so not allowed to send (proton will buffer locally)
2. No messages available from the application to send.

on_sendable() only covers the credit side: it fires when a sender that
had no credit is given some. In fact it may fire for other increases
where credit ends up > 0, but robust code should only assume it will
get at least one such notice, since credit can jump by increments more
than 1.

Proton has no way of knowing when messages become "available" in the
application, so if a sender runs out of application messages while it
still has credit then you cannot rely on on_sendable() to send further
messages. If the sender already has credit, there may not be any more
on_sendable() events even if the application generates messages to
send, since proton does not know about that.

A single threaded application can simply check sender credit and call
sender.send() directly when a message becomes available - see the
proton python example broker.

A multi-threaded application needs to take more care since the thread
that discovers a message is available may be running concurrently with
a thread processing the sender's connection. The c++ example broker
shows how to use inject() to send a notification to accomplish the same
thing in a thread-safe way.

The following basic pattern is common:

try_send() {
   while (credit>0 and have_messages()) {

on_sendable() { try_send() }

application_has_new_message() { try_send() }

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message