qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale Green <green.dale1...@gmail.com>
Subject Re: Service Bus: unreceived messages stay locked (peek-and-lock)
Date Thu, 21 Jul 2016 08:36:17 GMT
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.gemmell@gmail.com>
wrote:

> On 6 July 2016 at 17:57, Gordon Sim <gsim@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-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: users-help@qpid.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message