[Artemis] AMQP Acknowledge confirmation

[Krzysztof <h4...@gmail.com>]

Hi,

I am working on the implementation of AcceptAsync for AmqpNetLite but I
wasn't able to make Artemis issue any response to disposition frame with
the accepted state. Is this actually a supported feature? Maybe I am
missing sth.

Best,
Krzysztof

Re: [Artemis] AMQP Acknowledge confirmation

[Timothy Bish <ta...@gmail.com>]

On 5/10/20 12:44 PM, Krzysztof wrote:
> So as I said, I'm sending Disposition frame "amqp:disposition:list"
> with Accepted state "amqp:accepted:list". My assumption is that the broker
> should reply with the same, once the message is
> successfully acknowledged (aka removed from queue). Currently, AmqpNetLite
> sends dispositions is a fire-and-forget manner (sth like qpid-jms does
> with jms.forceAsyncAcks enabled) which isn't particularly safe, as the
> client cannot be sure that its disposition was processed.

Since the disposition frame carries more than just the delivery state I 
will have to guess based on the mention of Qpid JMS that you are doing 
something similar and your receiver attached with the Receiver 
Settlement Mode of first thereby indicating that your dispositions are 
also sent with the settled flag set to true along with the indicated 
accepted state.  If that is the case than the broker would not send you 
any response as you've settled thereby indicating that you have 
forgotten about delivery and removed it from the unsettled tracking on 
the receiver end.

You can refer to section 2.6.12 of the specification for a more in depth 
discussion of how the exchange of dispositions might occur based on the 
type of delivery semantics.



> For more context -->
> https://github.com/Azure/amqpnetlite/issues/367#issuecomment-517421722
>
> On Sun, May 10, 2020 at 5:46 PM Timothy Bish <ta...@gmail.com> wrote:
>
>> On 5/10/20 11:34 AM, Krzysztof wrote:
>>> Hi,
>>>
>>> I am working on the implementation of AcceptAsync for AmqpNetLite but I
>>> wasn't able to make Artemis issue any response to disposition frame with
>>> the accepted state. Is this actually a supported feature? Maybe I am
>>> missing sth.
>>>
>>> Best,
>>> Krzysztof
>>>
>> What frames are you sending and what frames are you wanting to get back,
>> it isn't entirely clear from this little context, a bit more specificity
>> might help here.
>>
>> --
>> Tim Bish
>>
>>

-- 
Tim Bish

Re: [Artemis] AMQP Acknowledge confirmation

[Timothy Bish <ta...@gmail.com>]

On 5/11/20 2:42 PM, Krzysztof wrote:
> If the broker doesn't support that I could set pie in the sky on my link
> and that would change nothing. :)

Given that would result in an invalid AMQP encoding for the link attach 
frame I'm pretty sure it would change something.


>
> On Mon, May 11, 2020 at 8:16 PM Timothy Bish <ta...@gmail.com> wrote:
>
>> On 5/11/20 1:33 PM, Krzysztof wrote:
>>> @Robbie
>>> I'm not sure what you mean by exactly-once. If you mentioned it in terms
>> of
>>> delivery semantics, then nope, I'm not sure that would be enough.
>>> Exactly-once is just a pipe dream, isn't it? Even if broker sends this
>> ack
>>> back, your client could die in the meantime.
>>>
>>> I would merely like to be sure that the broker has seen and processed the
>>> ack, that's it. The same way as it is done for message transfer. I'm
>>> sending the message to the broker and the broker replies: I've got it.
>>>
>>> @Timothy So I've tried to do it both ways. With settled=true and
>>> settled=false. And I got no reply. But as Robbie suggests, maybe the
>> broker
>>> just doesn't support this.
>> The broker doesn't support this and probably shouldn't unless you intend
>> to implement exactly once which as you say is not something likely to
>> ever actually work.  Your client likely is attaching with receiver
>> settlement mode of 'first' so even if you send a disposition which
>> carries an outcome without settling the broker is not required to
>> respond to you as you've indicated that you will settle first.
>>
>>
>>> On Mon, May 11, 2020 at 4:19 PM Robbie Gemmell <robbie.gemmell@gmail.com
>>>
>>> wrote:
>>>
>>>> Tim's reference will cover this, but essentially what you are
>>>> describing would only typically happen as part of doing exactly-once
>>>> if the client and broker had negotiated a receiver-settles-second link
>>>> rcv-settle-mode. The broker doesnt support that mode to my knowledge,
>>>> and so will indicate it is only doing receiver-settles-first. Even if
>>>> it did support it, most clients that might let you negotiate such a
>>>> rcv-settle-mode probably still cant do exactly-once as that also
>>>> requires fixed link names with unsettled state link resumption
>>>> negotiation (and some form of client side persistence to do that
>>>> properly) which I'm not aware of a client supporting.
>>>>
>>>> On Sun, 10 May 2020 at 17:44, Krzysztof <h4...@gmail.com> wrote:
>>>>> So as I said, I'm sending Disposition frame "amqp:disposition:list"
>>>>> with Accepted state "amqp:accepted:list". My assumption is that the
>>>> broker
>>>>> should reply with the same, once the message is
>>>>> successfully acknowledged (aka removed from queue). Currently,
>>>> AmqpNetLite
>>>>> sends dispositions is a fire-and-forget manner (sth like qpid-jms does
>>>>> with jms.forceAsyncAcks enabled) which isn't particularly safe, as the
>>>>> client cannot be sure that its disposition was processed.
>>>>>
>>>>> For more context -->
>>>>> https://github.com/Azure/amqpnetlite/issues/367#issuecomment-517421722
>>>>>
>>>>> On Sun, May 10, 2020 at 5:46 PM Timothy Bish <ta...@gmail.com>
>>>> wrote:
>>>>>> On 5/10/20 11:34 AM, Krzysztof wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am working on the implementation of AcceptAsync for AmqpNetLite
>>>> but I
>>>>>>> wasn't able to make Artemis issue any response to disposition frame
>>>> with
>>>>>>> the accepted state. Is this actually a supported feature? Maybe I am
>>>>>>> missing sth.
>>>>>>>
>>>>>>> Best,
>>>>>>> Krzysztof
>>>>>>>
>>>>>> What frames are you sending and what frames are you wanting to get
>>>> back,
>>>>>> it isn't entirely clear from this little context, a bit more
>>>> specificity
>>>>>> might help here.
>>>>>>
>>>>>> --
>>>>>> Tim Bish
>>>>>>
>>>>>>
>> --
>> Tim Bish
>>
>>

-- 
Tim Bish

Re: [Artemis] AMQP Acknowledge confirmation

[Krzysztof <h4...@gmail.com>]

If the broker doesn't support that I could set pie in the sky on my link
and that would change nothing. :)

On Mon, May 11, 2020 at 8:16 PM Timothy Bish <ta...@gmail.com> wrote:

> On 5/11/20 1:33 PM, Krzysztof wrote:
> > @Robbie
> > I'm not sure what you mean by exactly-once. If you mentioned it in terms
> of
> > delivery semantics, then nope, I'm not sure that would be enough.
> > Exactly-once is just a pipe dream, isn't it? Even if broker sends this
> ack
> > back, your client could die in the meantime.
> >
> > I would merely like to be sure that the broker has seen and processed the
> > ack, that's it. The same way as it is done for message transfer. I'm
> > sending the message to the broker and the broker replies: I've got it.
> >
> > @Timothy So I've tried to do it both ways. With settled=true and
> > settled=false. And I got no reply. But as Robbie suggests, maybe the
> broker
> > just doesn't support this.
>
> The broker doesn't support this and probably shouldn't unless you intend
> to implement exactly once which as you say is not something likely to
> ever actually work.  Your client likely is attaching with receiver
> settlement mode of 'first' so even if you send a disposition which
> carries an outcome without settling the broker is not required to
> respond to you as you've indicated that you will settle first.
>
>
> >
> > On Mon, May 11, 2020 at 4:19 PM Robbie Gemmell <robbie.gemmell@gmail.com
> >
> > wrote:
> >
> >> Tim's reference will cover this, but essentially what you are
> >> describing would only typically happen as part of doing exactly-once
> >> if the client and broker had negotiated a receiver-settles-second link
> >> rcv-settle-mode. The broker doesnt support that mode to my knowledge,
> >> and so will indicate it is only doing receiver-settles-first. Even if
> >> it did support it, most clients that might let you negotiate such a
> >> rcv-settle-mode probably still cant do exactly-once as that also
> >> requires fixed link names with unsettled state link resumption
> >> negotiation (and some form of client side persistence to do that
> >> properly) which I'm not aware of a client supporting.
> >>
> >> On Sun, 10 May 2020 at 17:44, Krzysztof <h4...@gmail.com> wrote:
> >>> So as I said, I'm sending Disposition frame "amqp:disposition:list"
> >>> with Accepted state "amqp:accepted:list". My assumption is that the
> >> broker
> >>> should reply with the same, once the message is
> >>> successfully acknowledged (aka removed from queue). Currently,
> >> AmqpNetLite
> >>> sends dispositions is a fire-and-forget manner (sth like qpid-jms does
> >>> with jms.forceAsyncAcks enabled) which isn't particularly safe, as the
> >>> client cannot be sure that its disposition was processed.
> >>>
> >>> For more context -->
> >>> https://github.com/Azure/amqpnetlite/issues/367#issuecomment-517421722
> >>>
> >>> On Sun, May 10, 2020 at 5:46 PM Timothy Bish <ta...@gmail.com>
> >> wrote:
> >>>> On 5/10/20 11:34 AM, Krzysztof wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I am working on the implementation of AcceptAsync for AmqpNetLite
> >> but I
> >>>>> wasn't able to make Artemis issue any response to disposition frame
> >> with
> >>>>> the accepted state. Is this actually a supported feature? Maybe I am
> >>>>> missing sth.
> >>>>>
> >>>>> Best,
> >>>>> Krzysztof
> >>>>>
> >>>> What frames are you sending and what frames are you wanting to get
> >> back,
> >>>> it isn't entirely clear from this little context, a bit more
> >> specificity
> >>>> might help here.
> >>>>
> >>>> --
> >>>> Tim Bish
> >>>>
> >>>>
>
> --
> Tim Bish
>
>

Re: [Artemis] AMQP Acknowledge confirmation

[Timothy Bish <ta...@gmail.com>]

On 5/11/20 1:33 PM, Krzysztof wrote:
> @Robbie
> I'm not sure what you mean by exactly-once. If you mentioned it in terms of
> delivery semantics, then nope, I'm not sure that would be enough.
> Exactly-once is just a pipe dream, isn't it? Even if broker sends this ack
> back, your client could die in the meantime.
>
> I would merely like to be sure that the broker has seen and processed the
> ack, that's it. The same way as it is done for message transfer. I'm
> sending the message to the broker and the broker replies: I've got it.
>
> @Timothy So I've tried to do it both ways. With settled=true and
> settled=false. And I got no reply. But as Robbie suggests, maybe the broker
> just doesn't support this.

The broker doesn't support this and probably shouldn't unless you intend 
to implement exactly once which as you say is not something likely to 
ever actually work.  Your client likely is attaching with receiver 
settlement mode of 'first' so even if you send a disposition which 
carries an outcome without settling the broker is not required to 
respond to you as you've indicated that you will settle first.


>
> On Mon, May 11, 2020 at 4:19 PM Robbie Gemmell <ro...@gmail.com>
> wrote:
>
>> Tim's reference will cover this, but essentially what you are
>> describing would only typically happen as part of doing exactly-once
>> if the client and broker had negotiated a receiver-settles-second link
>> rcv-settle-mode. The broker doesnt support that mode to my knowledge,
>> and so will indicate it is only doing receiver-settles-first. Even if
>> it did support it, most clients that might let you negotiate such a
>> rcv-settle-mode probably still cant do exactly-once as that also
>> requires fixed link names with unsettled state link resumption
>> negotiation (and some form of client side persistence to do that
>> properly) which I'm not aware of a client supporting.
>>
>> On Sun, 10 May 2020 at 17:44, Krzysztof <h4...@gmail.com> wrote:
>>> So as I said, I'm sending Disposition frame "amqp:disposition:list"
>>> with Accepted state "amqp:accepted:list". My assumption is that the
>> broker
>>> should reply with the same, once the message is
>>> successfully acknowledged (aka removed from queue). Currently,
>> AmqpNetLite
>>> sends dispositions is a fire-and-forget manner (sth like qpid-jms does
>>> with jms.forceAsyncAcks enabled) which isn't particularly safe, as the
>>> client cannot be sure that its disposition was processed.
>>>
>>> For more context -->
>>> https://github.com/Azure/amqpnetlite/issues/367#issuecomment-517421722
>>>
>>> On Sun, May 10, 2020 at 5:46 PM Timothy Bish <ta...@gmail.com>
>> wrote:
>>>> On 5/10/20 11:34 AM, Krzysztof wrote:
>>>>> Hi,
>>>>>
>>>>> I am working on the implementation of AcceptAsync for AmqpNetLite
>> but I
>>>>> wasn't able to make Artemis issue any response to disposition frame
>> with
>>>>> the accepted state. Is this actually a supported feature? Maybe I am
>>>>> missing sth.
>>>>>
>>>>> Best,
>>>>> Krzysztof
>>>>>
>>>> What frames are you sending and what frames are you wanting to get
>> back,
>>>> it isn't entirely clear from this little context, a bit more
>> specificity
>>>> might help here.
>>>>
>>>> --
>>>> Tim Bish
>>>>
>>>>

-- 
Tim Bish

Re: [Artemis] AMQP Acknowledge confirmation

[Krzysztof <h4...@gmail.com>]

@Robbie
I'm not sure what you mean by exactly-once. If you mentioned it in terms of
delivery semantics, then nope, I'm not sure that would be enough.
Exactly-once is just a pipe dream, isn't it? Even if broker sends this ack
back, your client could die in the meantime.

I would merely like to be sure that the broker has seen and processed the
ack, that's it. The same way as it is done for message transfer. I'm
sending the message to the broker and the broker replies: I've got it.

@Timothy So I've tried to do it both ways. With settled=true and
settled=false. And I got no reply. But as Robbie suggests, maybe the broker
just doesn't support this.

On Mon, May 11, 2020 at 4:19 PM Robbie Gemmell <ro...@gmail.com>
wrote:

> Tim's reference will cover this, but essentially what you are
> describing would only typically happen as part of doing exactly-once
> if the client and broker had negotiated a receiver-settles-second link
> rcv-settle-mode. The broker doesnt support that mode to my knowledge,
> and so will indicate it is only doing receiver-settles-first. Even if
> it did support it, most clients that might let you negotiate such a
> rcv-settle-mode probably still cant do exactly-once as that also
> requires fixed link names with unsettled state link resumption
> negotiation (and some form of client side persistence to do that
> properly) which I'm not aware of a client supporting.
>
> On Sun, 10 May 2020 at 17:44, Krzysztof <h4...@gmail.com> wrote:
> >
> > So as I said, I'm sending Disposition frame "amqp:disposition:list"
> > with Accepted state "amqp:accepted:list". My assumption is that the
> broker
> > should reply with the same, once the message is
> > successfully acknowledged (aka removed from queue). Currently,
> AmqpNetLite
> > sends dispositions is a fire-and-forget manner (sth like qpid-jms does
> > with jms.forceAsyncAcks enabled) which isn't particularly safe, as the
> > client cannot be sure that its disposition was processed.
> >
> > For more context -->
> > https://github.com/Azure/amqpnetlite/issues/367#issuecomment-517421722
> >
> > On Sun, May 10, 2020 at 5:46 PM Timothy Bish <ta...@gmail.com>
> wrote:
> >
> > > On 5/10/20 11:34 AM, Krzysztof wrote:
> > > > Hi,
> > > >
> > > > I am working on the implementation of AcceptAsync for AmqpNetLite
> but I
> > > > wasn't able to make Artemis issue any response to disposition frame
> with
> > > > the accepted state. Is this actually a supported feature? Maybe I am
> > > > missing sth.
> > > >
> > > > Best,
> > > > Krzysztof
> > > >
> > > What frames are you sending and what frames are you wanting to get
> back,
> > > it isn't entirely clear from this little context, a bit more
> specificity
> > > might help here.
> > >
> > > --
> > > Tim Bish
> > >
> > >
>

Re: [Artemis] AMQP Acknowledge confirmation

[Robbie Gemmell <ro...@gmail.com>]

Tim's reference will cover this, but essentially what you are
describing would only typically happen as part of doing exactly-once
if the client and broker had negotiated a receiver-settles-second link
rcv-settle-mode. The broker doesnt support that mode to my knowledge,
and so will indicate it is only doing receiver-settles-first. Even if
it did support it, most clients that might let you negotiate such a
rcv-settle-mode probably still cant do exactly-once as that also
requires fixed link names with unsettled state link resumption
negotiation (and some form of client side persistence to do that
properly) which I'm not aware of a client supporting.

On Sun, 10 May 2020 at 17:44, Krzysztof <h4...@gmail.com> wrote:
>
> So as I said, I'm sending Disposition frame "amqp:disposition:list"
> with Accepted state "amqp:accepted:list". My assumption is that the broker
> should reply with the same, once the message is
> successfully acknowledged (aka removed from queue). Currently, AmqpNetLite
> sends dispositions is a fire-and-forget manner (sth like qpid-jms does
> with jms.forceAsyncAcks enabled) which isn't particularly safe, as the
> client cannot be sure that its disposition was processed.
>
> For more context -->
> https://github.com/Azure/amqpnetlite/issues/367#issuecomment-517421722
>
> On Sun, May 10, 2020 at 5:46 PM Timothy Bish <ta...@gmail.com> wrote:
>
> > On 5/10/20 11:34 AM, Krzysztof wrote:
> > > Hi,
> > >
> > > I am working on the implementation of AcceptAsync for AmqpNetLite but I
> > > wasn't able to make Artemis issue any response to disposition frame with
> > > the accepted state. Is this actually a supported feature? Maybe I am
> > > missing sth.
> > >
> > > Best,
> > > Krzysztof
> > >
> > What frames are you sending and what frames are you wanting to get back,
> > it isn't entirely clear from this little context, a bit more specificity
> > might help here.
> >
> > --
> > Tim Bish
> >
> >

Re: [Artemis] AMQP Acknowledge confirmation

[Krzysztof <h4...@gmail.com>]

So as I said, I'm sending Disposition frame "amqp:disposition:list"
with Accepted state "amqp:accepted:list". My assumption is that the broker
should reply with the same, once the message is
successfully acknowledged (aka removed from queue). Currently, AmqpNetLite
sends dispositions is a fire-and-forget manner (sth like qpid-jms does
with jms.forceAsyncAcks enabled) which isn't particularly safe, as the
client cannot be sure that its disposition was processed.

For more context -->
https://github.com/Azure/amqpnetlite/issues/367#issuecomment-517421722

On Sun, May 10, 2020 at 5:46 PM Timothy Bish <ta...@gmail.com> wrote:

> On 5/10/20 11:34 AM, Krzysztof wrote:
> > Hi,
> >
> > I am working on the implementation of AcceptAsync for AmqpNetLite but I
> > wasn't able to make Artemis issue any response to disposition frame with
> > the accepted state. Is this actually a supported feature? Maybe I am
> > missing sth.
> >
> > Best,
> > Krzysztof
> >
> What frames are you sending and what frames are you wanting to get back,
> it isn't entirely clear from this little context, a bit more specificity
> might help here.
>
> --
> Tim Bish
>
>

Re: [Artemis] AMQP Acknowledge confirmation

[Timothy Bish <ta...@gmail.com>]

On 5/10/20 11:34 AM, Krzysztof wrote:
> Hi,
>
> I am working on the implementation of AcceptAsync for AmqpNetLite but I
> wasn't able to make Artemis issue any response to disposition frame with
> the accepted state. Is this actually a supported feature? Maybe I am
> missing sth.
>
> Best,
> Krzysztof
>
What frames are you sending and what frames are you wanting to get back, 
it isn't entirely clear from this little context, a bit more specificity 
might help here.

-- 
Tim Bish