Not really, as Gordon and I discussed below that they aren't wrong to overlook the disposition frames (which the client isnt sending itself, Proton is implicitly, and we should perhaps stop it doing so). The reasoning for ignoring them mentioned in the comment isn't quite correct, since disposition frames dont reference link handles at all and instead use the session scoped delivery numbers of the messages (http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-disposition) but in this particular case the end result is the same.
The point we seem to disagree on is rather what should happen when the link is closed. At that point the link terminus is destroyed without the messages having reached a terminal outcome specified by the client, at which point it is typical for the server to apply one. The session is still open, but the implicit dispositions still have no effect as discussed, which is fine. It does however mean that since no disposition can ever be applied by the client for those messages, it can never consume or release (or anything else) them explicitly. Its not clear why they would still be locked by the server in that case, as the consumer they were given to can never do anything to them at that point. Robbie On 21 July 2016 at 09:36, Dale Green <green.dale1...@gmail.com> wrote: > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
