On 17 November 2016 at 15:36, Adel Boutros <adelbout...@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.gemm...@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 <adelbout...@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 <acon...@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-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
