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-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
