qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: [Proton-c] [C++ bindings][0.14.0] How do I know a message was settled by the receiver?
Date Thu, 17 Nov 2016 16:25:06 GMT
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.
>

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


Mime
View raw message