On 6 July 2016 at 17:57, Gordon Sim <g...@redhat.com> wrote: > On 06/07/16 17:42, Gordon Sim wrote: >> >> On 06/07/16 17:14, Dale Green wrote: >>> >>> I have an update on this issue. >>> >>> According to Microsoft, state=Released is supported and now I can confirm >>> that this is true. If the message is released during the lifetime of the >>> consumer (before Detach), the same message is immediately unlocked and is >>> available for the same consumer or others depending on the credit. >>> >>> However, what happens with Qpid JMS is that messageConsumer.close() first >>> sends a Detach frame and after that the Disposition frames if any. Is >>> this >>> correct from protocol point of view, as Service Bus seems to ignore such >>> dispositions? >> >> >> The spec says: >> >> The disposition performative MAY refer to deliveries on links >> that are no longer attached. As long as the links have not been >> closed or detached with an error then the deliveries are still >> “live” and the updated state MUST be applied. >> >> If the Detach sent by the client has closed=true, then I would think >> that the deliveries associated with that link are implicitly ended. If >> this is the case, then the client has a bug. > > > Just to clarify on this last part. All I meant is that any disposition sent > after the close would not have any effect. So if the client intends to > explicitly release it should do so before closing. >
Agreed. Thats was part of my overly elaborate deleted reply hehe. As I say, it isnt actually the client doing the releasing, but proton. To do the releases explicitly the client would currently first need to drain the credit first, which we have already established would fail agaisnt ServiceBus from earlier mails in the thread. > >> (If the closed flag was false, then I would think it would depend on the >> expiry-policy for the link's source). >> >>> Is there any way to set the credit to 0, send the Dispositions, and then >>> Detach? >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org >> For additional commands, e-mail: users-h...@qpid.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
