On 10/02/2020 1:12 am, Chuck Rolke wrote:
----- Original Message -----
From: "Francesco Raviglione" <[email protected]>
To: [email protected]
Sent: Saturday, February 8, 2020 5:36:39 AM
Subject: Avoiding aggregation of "transfer" messages in Qpid Proton
Hello,
I'm sorry about the several questions I'm posting on the mailing list
during these days, but, unfortunately, I'm struggling a bit in the usage of
Qpid Proton (in particular, on the C version).
One issue I noticed, and that I was not able to solve, is related to the
fact that, when following and adapting the send.c example (available inside
the C API reference:
https://qpid.apache.org/releases/qpid-proton-0.30.0/proton/c/api/send_8c-example.html),
all the AMQP "transfer" messages are aggregated and if, for instance, I
send 200 messages, one every 100 ms (using an additional Linux timer), I
have to wait for 20 seconds before seeing them on the receiving side (an
ActiveMQ broker, in my case), as all the 200 transfers are aggregated into
a single, very big, AMQP message, which is sent only at the end of the
process.
This is something I would like to avoid, as it makes end-to-end message
delivery (from producer, to broker, to consumer) too slow.
Is there a way in which I can avoid this behaviour and make messages being
sent immediately?
Thank you very much in advance.
While you are in the PN_LINK_FLOW loop the calls to send_message are only
queueing
messages to proton. Proton can't start sending any of them until you return
from the
flow handler.
What you could do is send only so many (N) messages in the flow handler and
then exit.
Later the PN_DELIVERY callback will be activated and you can send more messages
there
to keep the N messages in flight.
While it is certainly true that you need to return control to the event
loop to allow any IO to happen, multiple calls to pn_message_send should
never be coalesced into a single large message as that method should
call pn_link_advance which creates a separate distinct message.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
