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 Fri, 18 Nov 2016 01:50:51 GMT
On Thu, 2016-11-17 at 16:25 +0000, Robbie Gemmell wrote:
> On 17 November 2016 at 16:02, Adel Boutros <Adelboutros@live.com>
> 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.

> 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 <robbie.gemmell@gmail.com>
> > Sent: Thursday, November 17, 2016 4:46:51 PM
> > To: users@qpid.apache.org
> > 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 <Adelboutros@live.com>
> > 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 <robbie.gemmell@gmail.com>
> > > Sent: Thursday, November 17, 2016 4:26 PM
> > > To: users@qpid.apache.org
> > > 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 <Adelboutros@live.com>
> > > 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 <aconway@redhat.com>
> > > > Sent: Thursday, November 17, 2016 3:22:17 PM
> > > > To: users@qpid.apache.org
> > > > 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: users-unsubscribe@qpid.apache.org
> > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > > 
> > > 
> > > ---------------------------------------------------------------
> > > ------
> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > > 
> > 
> > -----------------------------------------------------------------
> > ----
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 


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


Mime
View raw message