You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Adel Boutros <Ad...@live.com> on 2016/11/16 18:08:56 UTC
[Proton-c] [C++ bindings][0.14.0] How do I know a message was settled
by the receiver?
Hello,
I have a simple C++ client which connects to a Qpid Java Broker (6.0.4) and receives messages.
With the default behavior of the C++ client, how can I know when a delivery has been settled?
It seems there is no way for me to know that.
I have debugged a bit and when the on_message is called, the message becomes in "Acquired" state on the broker. Later on, somewhere which I haven't found yet, the message is settled and disappears from the broker. However none of the functions I implemented below is called.
Can you please assist?
Console output
-----------------------
on_message
Code
-----------------------
class MyHandler : public proton::messaging_handler
{
public:
virtual void on_container_start(proton::container &c)
{
proton::url url("localhost:5672");
proton::connection connection = c.connect(url);
proton::receiver_options receiverOptions(proton::receiver_options().credit_window(0));
connection.open_receiver("queue.name", receiverOptions);
}
virtual void on_receiver_open(proton::receiver& l)
{
l.add_credit(1);
}
virtual void on_message(proton::delivery &d, proton::message &m)
{
std::cout << "on_message" << std::endl;
}
virtual void on_delivery_settle(proton::delivery &d)
{
std::cout << "on_delivery_settle" << std::endl;
}
virtual void on_tracker_accept(proton::tracker &d)
{
std::cout << "on_tracker_accept" << std::endl;
}
virtual void on_tracker_reject(proton::tracker &d)
{
std::cout << "on_tracker_reject" << std::endl;
}
virtual void on_tracker_release(proton::tracker &d)
{
std::cout << "on_tracker_release" << std::endl;
}
virtual void on_tracker_settle(proton::tracker &d)
{
std::cout << "on_tracker_settle" << std::endl;
}
};
Regards,
Adel
Re: [Proton-c] [C++ bindings][0.14.0] How do I know a message was
settled by the receiver?
Posted by Robbie Gemmell <ro...@gmail.com>.
On 16 November 2016 at 18:08, Adel Boutros <Ad...@live.com> wrote:
> Hello,
>
>
> I have a simple C++ client which connects to a Qpid Java Broker (6.0.4) and receives messages.
>
> With the default behavior of the C++ client, how can I know when a delivery has been settled?
>
> It seems there is no way for me to know that.
>
>
> I have debugged a bit and when the on_message is called, the message becomes in "Acquired" state on the broker. Later on, somewhere which I haven't found yet, the message is settled and disappears from the broker. However none of the functions I implemented below is called.
>
To be clear, the message is acquired on the broker before it is ever
sent to the client. When (or if) the on_message fires exactly has no
bearing on that. After the handler returns, the message is then
accepted+settled (unless configured otherwise) and once the broekr
sees that its removed form the queue. This is the same as e.g the JMS
MessageListener case using auto ack.
Most of the methods you show below will only be called when
publishing, to let you know the broker has
accepted/rejected/etc+settled the message you sent (assuming it was
sent unsettled). In this case it is the client is accepting+settling,
and as soon as it does the broker can't update it about that message
again (because the client already considers it settled).
>
> Can you please assist?
>
>
> Console output
>
> -----------------------
>
> on_message
>
>
> Code
>
> -----------------------
>
>
> class MyHandler : public proton::messaging_handler
> {
> public:
>
> virtual void on_container_start(proton::container &c)
> {
> proton::url url("localhost:5672");
> proton::connection connection = c.connect(url);
> proton::receiver_options receiverOptions(proton::receiver_options().credit_window(0));
> connection.open_receiver("queue.name", receiverOptions);
> }
>
> virtual void on_receiver_open(proton::receiver& l)
> {
> l.add_credit(1);
> }
>
> virtual void on_message(proton::delivery &d, proton::message &m)
> {
> std::cout << "on_message" << std::endl;
> }
> virtual void on_delivery_settle(proton::delivery &d)
> {
> std::cout << "on_delivery_settle" << std::endl;
> }
> virtual void on_tracker_accept(proton::tracker &d)
> {
> std::cout << "on_tracker_accept" << std::endl;
> }
>
> virtual void on_tracker_reject(proton::tracker &d)
> {
> std::cout << "on_tracker_reject" << std::endl;
> }
>
> virtual void on_tracker_release(proton::tracker &d)
> {
> std::cout << "on_tracker_release" << std::endl;
> }
>
> virtual void on_tracker_settle(proton::tracker &d)
> {
> std::cout << "on_tracker_settle" << std::endl;
> }
> };
>
>
>
> Regards,
>
> Adel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Proton-c] [C++ bindings][0.14.0] How do I know a message was
settled by the receiver?
Posted by Adel Boutros <Ad...@live.com>.
I see. In my case, a handler can only handle one message at a time. I am setting the credit_window to 0 and adding 1 credit when the main thread is ready to receive the next message.
Adel
________________________________
From: Robbie Gemmell <ro...@gmail.com>
Sent: Thursday, November 17, 2016 5:25:06 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 16:02, Adel Boutros <Ad...@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.
>
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 <ro...@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 <Ad...@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 <ro...@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 <Ad...@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 <ac...@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
Re: [Proton-c] [C++ bindings][0.14.0] How do I know a message was
settled by the receiver?
Posted by Adel Boutros <Ad...@live.com>.
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 <ac...@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 <Ad...@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 <ro...@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 <Ad...@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 <ro...@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 <ac...@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
Re: [Proton-c] [C++ bindings][0.14.0] How do I know a message was
settled by the receiver?
Posted by Alan Conway <ac...@redhat.com>.
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 <Ad...@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 <ro...@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 <Ad...@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 <ro...@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 <ac...@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
Re: [Proton-c] [C++ bindings][0.14.0] How do I know a message was
settled by the receiver?
Posted by Alan Conway <ac...@redhat.com>.
On Thu, 2016-11-17 at 16:25 +0000, Robbie Gemmell wrote:
> On 17 November 2016 at 16:02, Adel Boutros <Ad...@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 <ro...@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 <Ad...@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 <ro...@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 <Ad...@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 <ac...@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
Re: [Proton-c] [C++ bindings][0.14.0] How do I know a message was
settled by the receiver?
Posted by Robbie Gemmell <ro...@gmail.com>.
On 17 November 2016 at 16:02, Adel Boutros <Ad...@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.
>
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 <ro...@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 <Ad...@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 <ro...@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 <Ad...@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 <ac...@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
Re: [Proton-c] [C++ bindings][0.14.0] How do I know a message was
settled by the receiver?
Posted by Adel Boutros <Ad...@live.com>.
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.
________________________________
From: Robbie Gemmell <ro...@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 <Ad...@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 <ro...@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 <Ad...@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 <ac...@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
Re: [Proton-c] [C++ bindings][0.14.0] How do I know a message was
settled by the receiver?
Posted by Robbie Gemmell <ro...@gmail.com>.
On 17 November 2016 at 15:36, Adel Boutros <Ad...@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 <ro...@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 <Ad...@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 <ac...@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
Re: [Proton-c] [C++ bindings][0.14.0] How do I know a message was
settled by the receiver?
Posted by Adel Boutros <Ad...@live.com>.
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?
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 <ro...@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 <Ad...@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 <ac...@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
Re: [Proton-c] [C++ bindings][0.14.0] How do I know a message was
settled by the receiver?
Posted by Robbie Gemmell <ro...@gmail.com>.
On 17 November 2016 at 14:39, Adel Boutros <Ad...@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 <ac...@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
Re: [Proton-c] [C++ bindings][0.14.0] How do I know a message was
settled by the receiver?
Posted by Adel Boutros <Ad...@live.com>.
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?
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?
Regards,
Adel
________________________________
From: Alan Conway <ac...@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
Re: [Proton-c] [C++ bindings][0.14.0] How do I know a message was
settled by the receiver?
Posted by Alan Conway <ac...@redhat.com>.
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
Re: [Proton-c] [C++ bindings][0.14.0] How do I know a message was
settled by the receiver?
Posted by Adel Boutros <Ad...@live.com>.
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).
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?
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.
messaging_adapter.cpp Code block myHandler is reaching
-----------------------------------------------------------------------------
delegate_.on_message(d, msg);
if (lctx.auto_accept && !d.settled())
d.accept(); //This is reached as well
messaging_adapter.cpp Full block code
-----------------------------------------------------------------------------
if (pn_link_is_receiver(lnk)) {
delivery d(make_wrapper<delivery>(dlv));
if (!pn_delivery_partial(dlv) && pn_delivery_readable(dlv)) {
// generate on_message
pn_connection_t *pnc = pn_session_connection(pn_link_session(lnk));
connection_context& ctx = connection_context::get(pnc);
// Reusable per-connection message.
// Avoid expensive heap malloc/free overhead.
// See PROTON-998
class message &msg(ctx.event_message);
msg.decode(d);
if (pn_link_state(lnk) & PN_LOCAL_CLOSED) {
if (lctx.auto_accept)
d.release();
} else {
delegate_.on_message(d, msg);
if (lctx.auto_accept && !d.settled())
d.accept();
if (lctx.draining && !pn_link_credit(lnk)) {
lctx.draining = false;
receiver r(make_wrapper<receiver>(lnk));
delegate_.on_receiver_drain_finish(r);
}
}
}
else if (pn_delivery_updated(dlv) && d.settled()) {
delegate_.on_delivery_settle(d);
}
if (lctx.draining && pn_link_credit(lnk) == 0) {
lctx.draining = false;
pn_link_set_drain(lnk, false);
receiver r(make_wrapper<receiver>(lnk));
delegate_.on_receiver_drain_finish(r);
if (lctx.pending_credit) {
pn_link_flow(lnk, lctx.pending_credit);
lctx.pending_credit = 0;
}
}
credit_topup(lnk);
}
________________________________
From: Adel Boutros <Ad...@live.com>
Sent: Wednesday, November 16, 2016 7:08:56 PM
To: users@qpid.apache.org
Subject: [Proton-c] [C++ bindings][0.14.0] How do I know a message was settled by the receiver?
Hello,
I have a simple C++ client which connects to a Qpid Java Broker (6.0.4) and receives messages.
With the default behavior of the C++ client, how can I know when a delivery has been settled?
It seems there is no way for me to know that.
I have debugged a bit and when the on_message is called, the message becomes in "Acquired" state on the broker. Later on, somewhere which I haven't found yet, the message is settled and disappears from the broker. However none of the functions I implemented below is called.
Can you please assist?
Console output
-----------------------
on_message
Code
-----------------------
class MyHandler : public proton::messaging_handler
{
public:
virtual void on_container_start(proton::container &c)
{
proton::url url("localhost:5672");
proton::connection connection = c.connect(url);
proton::receiver_options receiverOptions(proton::receiver_options().credit_window(0));
connection.open_receiver("queue.name", receiverOptions);
}
virtual void on_receiver_open(proton::receiver& l)
{
l.add_credit(1);
}
virtual void on_message(proton::delivery &d, proton::message &m)
{
std::cout << "on_message" << std::endl;
}
virtual void on_delivery_settle(proton::delivery &d)
{
std::cout << "on_delivery_settle" << std::endl;
}
virtual void on_tracker_accept(proton::tracker &d)
{
std::cout << "on_tracker_accept" << std::endl;
}
virtual void on_tracker_reject(proton::tracker &d)
{
std::cout << "on_tracker_reject" << std::endl;
}
virtual void on_tracker_release(proton::tracker &d)
{
std::cout << "on_tracker_release" << std::endl;
}
virtual void on_tracker_settle(proton::tracker &d)
{
std::cout << "on_tracker_settle" << std::endl;
}
};
Regards,
Adel