qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: [Proton-c] [C++ bindings][0.14.0] How do I know a message was settled by the receiver?
Date Thu, 17 Nov 2016 14:22:17 GMT
On Thu, 2016-11-17 at 08:41 +0000, Adel Boutros wrote:
> I would like to add a bit of context. My C++ client has a method
> called "receiveTextMessage()". This method is supposed to simulate
> what JMS.receiveMessage() does which is block until a message is
> received and settled.
> 
> 
> So, I am using wait/notify mechanism to unblock my consumer when the
> message is settled and no longer available on the broker.
> 
> It seems in the code, when the auto_accept is set to true (default
> behavior), there is no way to be notified when the delivery is
> settled and only on_message will be called
> (proton::messaging_adapter.cpp).

auto-accept() is no different from calling accept() at the end of your
on_message() - feel free to turn it off if you want more control. 

auto vs. manual doesn't change the events you see. It depends on how
your receiver delivery_mode:

AT_MOST_ONCE: sent pre-settled, unreliable, fire-and-forget.

AT_LEAST_ONCE: receiver-settles-first: receiver settles before sending
accept, will not get any notification of outcome. There may be
duplicates if accepts are lost.

AMQP also offers: receiver-settles-second - this is the most reliable
"3-way-ack" receiver sends accept but doesn't settle, sender settles on
getting accept, receiver settles after sender. This can be used to
implement the holy grail of "EXACTLY_ONCE" but it requires a lot of
state to be tracked. Proton doesn't have built-in support for it and
the C++ API lacks a delivery_mode to set it (but that's easy to fix)

> In that case, between the time MyHandler::on_message is called and
> the time where the message is settled (d.accept() in the below code),
> can't anything go wrong?

Yes, the network can break and you have no idea if the accept made it
which means you re-queue the message and may potentially send a
duplicate. This is acceptable for AT_LEAST_ONCE, the application needs
to handle de-duplication (that's the part that's hard to do in a
generic and efficient way)

> PS: As the event_loop has performance issues, I am using the
> timerTask and schedule for the interaction between the consumer main
> thread and the handler thread.

Thanks, the issue will be fixed I promise.


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


Mime
View raw message