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

Reply via email to