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] Closing a Message Group AMQP
Thank you, Robbie, for your answer. I will try to use it that way. What do you think about updating the docs to make it more explicit for not JMS users? On Mon, May 11, 2020 at 4:20 PM Robbie Gemmell wrote: > On Sun, 10 May 2020 at 19:19, Krzysztof wrote: > > > > Hi, > > > > I'm trying to use the Closing Message Group feature using AmqpNetLite. In > > docs it is stated that I should set "JMSXGroupSeq" to -1. In AMQP > protocol > > it maps however to group-sequence property which is of unsigned long > type. > > To be clear it is of type sequence-no, which is [essentially] a uint > (not a ulong). > > > The question is: do we implicitly rely on ulong overflow to make this > > feature work? At least for amqp based clients of course. If any case, > > shouldn't we update the docs to make it explicit? > > > > For the AMQP JMS mapping we defined that group-sequence uint values > 2^31 to 2^32 - 1 were mapped to JMSXGroupSeq signed int values -2^31 > to -1. > > i.e basically the uint 2^32-1 would become the -1. >
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] Closing a Message Group AMQP
On Sun, 10 May 2020 at 19:19, Krzysztof wrote: > > Hi, > > I'm trying to use the Closing Message Group feature using AmqpNetLite. In > docs it is stated that I should set "JMSXGroupSeq" to -1. In AMQP protocol > it maps however to group-sequence property which is of unsigned long type. To be clear it is of type sequence-no, which is [essentially] a uint (not a ulong). > The question is: do we implicitly rely on ulong overflow to make this > feature work? At least for amqp based clients of course. If any case, > shouldn't we update the docs to make it explicit? > For the AMQP JMS mapping we defined that group-sequence uint values 2^31 to 2^32 - 1 were mapped to JMSXGroupSeq signed int values -2^31 to -1. i.e basically the uint 2^32-1 would become the -1.
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 > > > >