qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adel Boutros <Adelbout...@live.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 08:14:52 GMT
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 <aconway@redhat.com>
Sent: Friday, November 18, 2016 2:54:50 AM
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 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 <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.
>

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 <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.co
> > > > 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 <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
>


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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message