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 <tabish...@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.gemm...@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 <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 > >>>> > >>>> > > -- > Tim Bish > >
