Hello Alan,
No you were correct. I am using C++ bindings. As for the sender, it is the Qpid Java Broker. So, the on_tracker callbacks cannot be used. Regards, Adel ________________________________ From: Alan Conway <[email protected]> Sent: Friday, November 18, 2016 2:54:50 AM 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 20:50 -0500, Alan Conway wrote: > On Thu, 2016-11-17 at 16:25 +0000, Robbie Gemmell wrote: > > > > On 17 November 2016 at 16:02, Adel Boutros <[email protected]> > > wrote: > > > > > > > > > Great! > > > > > > So, we agree in the JMS behavior we have at least sent the > > > disposition. > > > > > > > > > This is what I want to replicate using proton-c but still I > > > haven't > > > found out how because the on_message doesn't handle the > > > disposition > > > and I haven't figured out another way. > > > > > PN_CPP_EXTERN virtual void on_message(delivery &d, message &m); > > on_message is the receiver side. If the messages is not pre-settled > (delivery_mode == AT_LEAST_ONCE) then the receiver can call > d.accept(), > d.reject() etc. to send disposition back to the sender. The sender > will > get an on_tracker_accept(), on_tracker_reject() etc. message. > Sorry, you said C: everything is done on the pn_delivery_t, which represents both ends of the deliver. Your receiver should make these two calls in order: pn_delivery_update(pn_delivery_t *delivery, uint64_t state); pn_delivery_settle(pn_delivery_t *delivery); Your sender will get PN_DELIVERY events and can examine the delivery. > > > > I think the difference between them is that the c handler might > > fire > > for all the messages that arrived in a given socket read before the > > outgoing data including the dispositions (set at the point of the > > handler return) gets processed and sent, whereas the JMS client > > can't > > do that style of operation with this being somewhat tied to the > > very > > different ways they work under and over the hood. > > > > > > > > > > > ________________________________ > > > From: Robbie Gemmell <[email protected]> > > > Sent: Thursday, November 17, 2016 4:46:51 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 17 November 2016 at 15:36, Adel Boutros <[email protected]> > > > wrote: > > > > > > > > > > > > Hello Robbie, > > > > > > > > > > > > I think I wasn't clear enough. So let me explain. > > > > > > > > > > > > JMS > > > > > > > > ----------- > > > > > > > > Session session = connection.createSession(false, > > > > Session.AUTO_ACKNOWLEDGE); > > > > > > > > MessageConsumer consumer = > > > > session.createConsumer(session.createQueue("queue.name")); > > > > consumer.receive(); > > > > > > > > In the above code, when "receive" returns the message is no > > > > longer present on the broker. This is guaranteed. Is this > > > > statement correct? > > > > > > > > > > You were clear, I guess I wasn't. In the above, the client has > > > sent > > > disposition indicating its accepted+settled the message. It can > > > no > > > longer operate on that message or be told about changes in its > > > state. > > > The broker may not yet have seen the disposition. > > > > > > > > > > > > > > > Proton-c > > > > -------------- > > > > on_message() > > > > > > > > When on_message finished processing, I have no guarantee the > > > > message is no longer present on the broker as above. > > > > In the reactor code, the message disappears from the broker > > > > when > > > > PN_REACTOR_QUIESCED event is handled after the message was > > > > received (disposition event is sent to the broker). > > > > > > > > So my question here is how can I replicate the JMS behavior? > > > > > > > > Regards, > > > > Adel > > > > > > > > ________________________________ > > > > From: Robbie Gemmell <[email protected]> > > > > Sent: Thursday, November 17, 2016 4:26 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 17 November 2016 at 14:39, Adel Boutros <[email protected] > > > > m> > > > > 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] > > > > > > > > > > ----------------------------------------------------------------- > > > ---- > > > 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] > > > > > --------------------------------------------------------------------- > 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]
