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 <h4v...@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 <tabish...@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 > > > >
