On 17 November 2016 at 14:39, Adel Boutros <[email protected]> wrote: > Thank you Alan for your response! However, I am still a bit lost. > > > So you are saying that today there is no way to guarantee that a received > message has been settled without having to treat duplication. Is that correct? > > > I still have 2 questions then: > > 1. When will messaging_handler::on_delivery_settle be called? >
My guess is it wont currently, if the client settles the message while it accepts then the delivery is settled as far as the client is concerned. > 2. How does Qpid JMS guarantee the settlement of the received messages > knowing it is based on proton-j which behaves to some extent the same way > proton-c does? > It doesnt behave any differently than described above/previous mail. The client settles it when accepting then thats it, the message is settled as far as the client is concerned. > Regards, > > Adel > > ________________________________ > From: Alan Conway <[email protected]> > Sent: Thursday, November 17, 2016 3:22:17 PM > To: [email protected] > Subject: Re: [Proton-c] [C++ bindings][0.14.0] How do I know a message was > settled by the receiver? > > 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
