Re: [Artemis] AMQP Acknowledge confirmation
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 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 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 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 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
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 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 > > > 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 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 > >> 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
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 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 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 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
@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 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 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 > 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
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 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 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
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 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
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 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
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
