Jonathan Robie wrote:
In the examples we have written for C++ and Python, the need to allocate
credit explicitly in order to receive messages is one of the harder
things to explain to beginners.
Consider the following code:
connection.open(host, port);
Session session = connection.newSession();
session.messageSubscribe(arg::queue="message_queue",
arg::destination="listener_destination");
//############## Gripe, gripe, grumble, grumble ....
session.messageFlow(arg::destination="listener_destination",
arg::unit=0, arg::value=1);//messages ### Define a constant?
session.messageFlow(arg::destination="listener_destination",
arg::unit=1, arg::value=0xFFFFFFFF);//bytes ###### Define a constant?
Listener listener(session, "listener_destination");
listener.listen();
I understand that in the future there will be constants for arg::unit,
that helps some. But what would really help is a sensible default for
credit, because beginners or people writing a first prototype probably
do not know what values to set for these, and it would really be better
to explain the concept of credit in later examples, not in the first
(otherwise) simple examples.
Is there any reason these do not have sensible defaults that would allow
people to receive messages without explicitly allocating credit?
(Obviously, any explicit allocation would override these defaults.)
Yes. We are directly exposing the AMQP protocol as session commands, and
AMQP defines creating a subscriber and setting its credit as separate
commands. So any method we provide for creating a subscriber and
automatically setting credit must be a wrapper for the atomic commands.
That is exactly what SubscriptionManager is supposed to be, if it's
turning out to be difficult to use then we need a different wrapper.
What guidelines should we give users for setting these values when they
do explicitly allocate credit?
Windowed flow control limits the total memory that may be consumed on
the client for messages downloaded but not yet processed, and limits the
number of messages that may be put-back out of order if your client
receives but fails to acknowledge some messages, e.g. crashes or decides
to stop processing messages while there are still some in the window.
Non-windowed flow control is an efficient way to download a fixed number
of messages, when the client knows in advance how many they want.
I still think we need a higher-level API over the raw AMQP layer but I
don't know if we'll have time to do it given all the other things we
have on our plates.
Cheers,
Alan.
