Hi again, I got some answers from Microsoft here (in the comments after the article):
https://azure.microsoft.com/en-us/documentation/articles/service-bus-amqp-protocol-guide/ Looks like they have different opinion about the Disposition frames. On Wed, Jul 6, 2016 at 7:03 PM, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > 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 > >
