You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Dale Green <gr...@gmail.com> on 2016/07/06 16:14:36 UTC
Re: Service Bus: unreceived messages stay locked (peek-and-lock)
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?
Is there any way to set the credit to 0, send the Dispositions, and then
Detach?
Thanks!
On Thu, Jun 30, 2016 at 4:59 PM, Robbie Gemmell <ro...@gmail.com>
wrote:
> Thanks for the update. That seems to confirm that theres not much the
> client can do to help here, as both of the mechanisms it could use to
> assist in this situation (explicitly releasing unconsumed messages, or
> doing no prefetching to begin with) appear to be running into server
> bugs, in this case the snippet Gordon linked to.
>
> Robbie
>
> On 30 June 2016 at 15:42, Dale Green <gr...@gmail.com> wrote:
> > Sorry for the misunderstanding: The code I was testing is actually
> closing
> > the consumer explicitly.
> >
> > However, I tested now the Receiver example and can confirm, that it
> doesn't
> > matter for the server if the consumer is closed or not.
> > I can see that
> > messageConsumer.close();
> > produces such log lines for the prefetched messages:
> > SENT: Disposition{role=RECEIVER, first=7, last=7, settled=true,
> > state=Released{}, batchable=false}
> >
> > But the same messages are still locked for the lock duration.
> >
> >
> > On Thu, Jun 30, 2016 at 1:13 AM, Robbie Gemmell <
> robbie.gemmell@gmail.com>
> > wrote:
> >
> >> On 29 June 2016 at 11:08, Dale Green <gr...@gmail.com> wrote:
> >> > Hi Robbie,
> >> >
> >> > Thanks for the hints! I couldn't solve my problems, but let me leave
> some
> >> > more info, which can be useful for other people.
> >> >
> >> > Closing the consumer explicitly didn't help (it's closed on session
> close
> >> > anyway). However, I have the feeling that the lifetime of the consumer
> >> does
> >> > not affect the peek lock (imagine a long-running consumer: it doesn't
> >> lock
> >> > the messages for longer than the lock duration).
> >> >
> >>
> >> After sending my last reply to Gordon, I noticed something in your
> >> wording that I'd now like to double check. When I asked if you tried
> >> closing the consumer explicitly I meant before closing the session
> >> object, i.e:
> >> consumer.close();
> >> session.close();
> >>
> >> Can you confirm that is what you updated your code to do?
> >>
> >> > Setting the prefetch value to 1 didn't help as the next message comes
> to
> >> > the consumer immediately after receive(). So, there could be 0 or 1
> >> locked
> >> > messages after each consumer.
> >> >
> >> > Setting the prefetch value to 0 brings me back to the drain problem:
> >> > Service Bus doesn't answer anything after the sent packet with
> >> 'drain=true'
> >> > , so receive() is blocked forever. However, there are some (probably
> >> empty)
> >> > AMQP packets sent after some time, but Qpid doesn't send anything
> >> anymore.
> >> >
> >> >
> >> > On Tue, Jun 28, 2016 at 6:34 PM, Robbie Gemmell <
> >> robbie.gemmell@gmail.com>
> >> > wrote:
> >> >
> >> >> On 28 June 2016 at 17:00, Dale Green <gr...@gmail.com>
> wrote:
> >> >> > Hi people,
> >> >> >
> >> >> > I have a problem using Qpid JMS 0.9 with Service Bus.
> >> >> >
> >> >> > The use case is the following:
> >> >> > I want to create a connection, session, and a queue consumer and
> >> receive
> >> >> 0
> >> >> > or 1 messages within a given timeout. That is, receive(timeout) is
> >> called
> >> >> > only once. Immediately after that, the session and the connection
> are
> >> >> > closed.
> >> >> >
> >> >> > The problem is:
> >> >> > The consumer may receive multiple messages during its lifetime
> (which
> >> the
> >> >> > client code doesn't even see, because receive is called only once).
> >> For
> >> >> > Service Bus, all this means peek-and-lock, so the messages that
> were
> >> sent
> >> >> > to the Qpid client are locked for the time set in the "Lock
> Duration"
> >> >> > property of the queue (default value is 30s/60s, Azure/Windows),
> and
> >> >> > therefore they are unavailable for other Qpid consumers for a
> certain
> >> >> > period of time. I would expect that something like the method
> >> Abandon()
> >> >> > from the C# API should happen on session close.
> >> >> >
> >> >> > So:
> >> >> > Is this a bug, feature, or I need to configure/call something in a
> >> >> > different way?
> >> >> >
> >> >> > Thanks!
> >> >>
> >> >> My guess is that ServiceBus is not taking the consumers implicit
> >> >> detachment when the session ends as reason to release the messages.
> >> >> Perhaps try explicitly closing the MessageConsumer (I'm taking your
> >> >> text above literally, such that you arent doing so currently) to see
> >> >> if that prods it into doing so?
> >> >>
> >> >> Another thing you could to help is if you know you want at most 1
> >> >> message is to only give 1 message credit at a time (setting the
> >> >> prefetch config to 1 or 0...though the earlier server issue you ran
> >> >> into around 'drain' behaviour may mean this doesnt work so well)
> >> >>
> >> >> Robbie
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> 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
>
>
Re: Service Bus: unreceived messages stay locked (peek-and-lock)
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <gr...@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 <ro...@gmail.com>
> wrote:
>
>> On 6 July 2016 at 17:57, Gordon Sim <gs...@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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Service Bus: unreceived messages stay locked (peek-and-lock)
Posted by Dale Green <gr...@gmail.com>.
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 <ro...@gmail.com>
wrote:
> On 6 July 2016 at 17:57, Gordon Sim <gs...@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
>
>
Re: Service Bus: unreceived messages stay locked (peek-and-lock)
Posted by Robbie Gemmell <ro...@gmail.com>.
On 6 July 2016 at 17:57, Gordon Sim <gs...@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
Re: Service Bus: unreceived messages stay locked (peek-and-lock)
Posted by Gordon Sim <gs...@redhat.com>.
On 06/07/16 17:57, Gordon Sim 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
>> \u201clive\u201d 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.
And if the link is indeed closed, then arguably it makes no sense for
the server to keep any unsettled messages on it in the locked state.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Service Bus: unreceived messages stay locked (peek-and-lock)
Posted by Gordon Sim <gs...@redhat.com>.
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
> \u201clive\u201d 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.
> (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
Re: Service Bus: unreceived messages stay locked (peek-and-lock)
Posted by Gordon Sim <gs...@redhat.com>.
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
\u201clive\u201d 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.
(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
Re: Service Bus: unreceived messages stay locked (peek-and-lock)
Posted by Robbie Gemmell <ro...@gmail.com>.
On 6 July 2016 at 17:50, Robbie Gemmell <ro...@gmail.com> wrote:
> Hi Dale,
>
> It isnt invalid from a protocol perspective, as dispositions only
> actually refer to session-scoped information, not link
> (consumer/producer) scoped information. I deleted an overly
> complicated description <here> of why that is. ServiceBus isnt
> necessarily wrong in ignoring the dispositions given some of those
> complicated bits I've deleted (in parts to do with things Gordon
> referred to), but in doing so it itself indicating the messages should
> not be locked any more: if the dispositions are ignored, then noone
> can release or consume those messages at that point, so why continue
> to lock them?
>
> The client doesnt currently reduce credit to 0 before detaching as
> doing so would only mainly just add an extra round trip to the
> process.
Well, to be entirely accurate, it does have one way, configuring 0
prefetch, thats just not possible here as it cant worth against
ServiceBus. Thats also the same mechanism we would likely use to
implement such behaviour in the non-0 prefetch case though, meaning
that approach also wouldnt work against ServiceBus currently.
>
> (As an aside, it is actually Proton sending the disposistions
> implicitly rather than the client doing so directly)
>
> Robbie
>
> On 6 July 2016 at 17:14, Dale Green <gr...@gmail.com> 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?
>>
>> Is there any way to set the credit to 0, send the Dispositions, and then
>> Detach?
>>
>> Thanks!
>>
>> On Thu, Jun 30, 2016 at 4:59 PM, Robbie Gemmell <ro...@gmail.com>
>> wrote:
>>
>>> Thanks for the update. That seems to confirm that theres not much the
>>> client can do to help here, as both of the mechanisms it could use to
>>> assist in this situation (explicitly releasing unconsumed messages, or
>>> doing no prefetching to begin with) appear to be running into server
>>> bugs, in this case the snippet Gordon linked to.
>>>
>>> Robbie
>>>
>>> On 30 June 2016 at 15:42, Dale Green <gr...@gmail.com> wrote:
>>> > Sorry for the misunderstanding: The code I was testing is actually
>>> closing
>>> > the consumer explicitly.
>>> >
>>> > However, I tested now the Receiver example and can confirm, that it
>>> doesn't
>>> > matter for the server if the consumer is closed or not.
>>> > I can see that
>>> > messageConsumer.close();
>>> > produces such log lines for the prefetched messages:
>>> > SENT: Disposition{role=RECEIVER, first=7, last=7, settled=true,
>>> > state=Released{}, batchable=false}
>>> >
>>> > But the same messages are still locked for the lock duration.
>>> >
>>> >
>>> > On Thu, Jun 30, 2016 at 1:13 AM, Robbie Gemmell <
>>> robbie.gemmell@gmail.com>
>>> > wrote:
>>> >
>>> >> On 29 June 2016 at 11:08, Dale Green <gr...@gmail.com> wrote:
>>> >> > Hi Robbie,
>>> >> >
>>> >> > Thanks for the hints! I couldn't solve my problems, but let me leave
>>> some
>>> >> > more info, which can be useful for other people.
>>> >> >
>>> >> > Closing the consumer explicitly didn't help (it's closed on session
>>> close
>>> >> > anyway). However, I have the feeling that the lifetime of the consumer
>>> >> does
>>> >> > not affect the peek lock (imagine a long-running consumer: it doesn't
>>> >> lock
>>> >> > the messages for longer than the lock duration).
>>> >> >
>>> >>
>>> >> After sending my last reply to Gordon, I noticed something in your
>>> >> wording that I'd now like to double check. When I asked if you tried
>>> >> closing the consumer explicitly I meant before closing the session
>>> >> object, i.e:
>>> >> consumer.close();
>>> >> session.close();
>>> >>
>>> >> Can you confirm that is what you updated your code to do?
>>> >>
>>> >> > Setting the prefetch value to 1 didn't help as the next message comes
>>> to
>>> >> > the consumer immediately after receive(). So, there could be 0 or 1
>>> >> locked
>>> >> > messages after each consumer.
>>> >> >
>>> >> > Setting the prefetch value to 0 brings me back to the drain problem:
>>> >> > Service Bus doesn't answer anything after the sent packet with
>>> >> 'drain=true'
>>> >> > , so receive() is blocked forever. However, there are some (probably
>>> >> empty)
>>> >> > AMQP packets sent after some time, but Qpid doesn't send anything
>>> >> anymore.
>>> >> >
>>> >> >
>>> >> > On Tue, Jun 28, 2016 at 6:34 PM, Robbie Gemmell <
>>> >> robbie.gemmell@gmail.com>
>>> >> > wrote:
>>> >> >
>>> >> >> On 28 June 2016 at 17:00, Dale Green <gr...@gmail.com>
>>> wrote:
>>> >> >> > Hi people,
>>> >> >> >
>>> >> >> > I have a problem using Qpid JMS 0.9 with Service Bus.
>>> >> >> >
>>> >> >> > The use case is the following:
>>> >> >> > I want to create a connection, session, and a queue consumer and
>>> >> receive
>>> >> >> 0
>>> >> >> > or 1 messages within a given timeout. That is, receive(timeout) is
>>> >> called
>>> >> >> > only once. Immediately after that, the session and the connection
>>> are
>>> >> >> > closed.
>>> >> >> >
>>> >> >> > The problem is:
>>> >> >> > The consumer may receive multiple messages during its lifetime
>>> (which
>>> >> the
>>> >> >> > client code doesn't even see, because receive is called only once).
>>> >> For
>>> >> >> > Service Bus, all this means peek-and-lock, so the messages that
>>> were
>>> >> sent
>>> >> >> > to the Qpid client are locked for the time set in the "Lock
>>> Duration"
>>> >> >> > property of the queue (default value is 30s/60s, Azure/Windows),
>>> and
>>> >> >> > therefore they are unavailable for other Qpid consumers for a
>>> certain
>>> >> >> > period of time. I would expect that something like the method
>>> >> Abandon()
>>> >> >> > from the C# API should happen on session close.
>>> >> >> >
>>> >> >> > So:
>>> >> >> > Is this a bug, feature, or I need to configure/call something in a
>>> >> >> > different way?
>>> >> >> >
>>> >> >> > Thanks!
>>> >> >>
>>> >> >> My guess is that ServiceBus is not taking the consumers implicit
>>> >> >> detachment when the session ends as reason to release the messages.
>>> >> >> Perhaps try explicitly closing the MessageConsumer (I'm taking your
>>> >> >> text above literally, such that you arent doing so currently) to see
>>> >> >> if that prods it into doing so?
>>> >> >>
>>> >> >> Another thing you could to help is if you know you want at most 1
>>> >> >> message is to only give 1 message credit at a time (setting the
>>> >> >> prefetch config to 1 or 0...though the earlier server issue you ran
>>> >> >> into around 'drain' behaviour may mean this doesnt work so well)
>>> >> >>
>>> >> >> Robbie
>>> >> >>
>>> >> >> ---------------------------------------------------------------------
>>> >> >> 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
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Service Bus: unreceived messages stay locked (peek-and-lock)
Posted by Robbie Gemmell <ro...@gmail.com>.
Hi Dale,
It isnt invalid from a protocol perspective, as dispositions only
actually refer to session-scoped information, not link
(consumer/producer) scoped information. I deleted an overly
complicated description <here> of why that is. ServiceBus isnt
necessarily wrong in ignoring the dispositions given some of those
complicated bits I've deleted (in parts to do with things Gordon
referred to), but in doing so it itself indicating the messages should
not be locked any more: if the dispositions are ignored, then noone
can release or consume those messages at that point, so why continue
to lock them?
The client doesnt currently reduce credit to 0 before detaching as
doing so would only mainly just add an extra round trip to the
process.
(As an aside, it is actually Proton sending the disposistions
implicitly rather than the client doing so directly)
Robbie
On 6 July 2016 at 17:14, Dale Green <gr...@gmail.com> 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?
>
> Is there any way to set the credit to 0, send the Dispositions, and then
> Detach?
>
> Thanks!
>
> On Thu, Jun 30, 2016 at 4:59 PM, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
>> Thanks for the update. That seems to confirm that theres not much the
>> client can do to help here, as both of the mechanisms it could use to
>> assist in this situation (explicitly releasing unconsumed messages, or
>> doing no prefetching to begin with) appear to be running into server
>> bugs, in this case the snippet Gordon linked to.
>>
>> Robbie
>>
>> On 30 June 2016 at 15:42, Dale Green <gr...@gmail.com> wrote:
>> > Sorry for the misunderstanding: The code I was testing is actually
>> closing
>> > the consumer explicitly.
>> >
>> > However, I tested now the Receiver example and can confirm, that it
>> doesn't
>> > matter for the server if the consumer is closed or not.
>> > I can see that
>> > messageConsumer.close();
>> > produces such log lines for the prefetched messages:
>> > SENT: Disposition{role=RECEIVER, first=7, last=7, settled=true,
>> > state=Released{}, batchable=false}
>> >
>> > But the same messages are still locked for the lock duration.
>> >
>> >
>> > On Thu, Jun 30, 2016 at 1:13 AM, Robbie Gemmell <
>> robbie.gemmell@gmail.com>
>> > wrote:
>> >
>> >> On 29 June 2016 at 11:08, Dale Green <gr...@gmail.com> wrote:
>> >> > Hi Robbie,
>> >> >
>> >> > Thanks for the hints! I couldn't solve my problems, but let me leave
>> some
>> >> > more info, which can be useful for other people.
>> >> >
>> >> > Closing the consumer explicitly didn't help (it's closed on session
>> close
>> >> > anyway). However, I have the feeling that the lifetime of the consumer
>> >> does
>> >> > not affect the peek lock (imagine a long-running consumer: it doesn't
>> >> lock
>> >> > the messages for longer than the lock duration).
>> >> >
>> >>
>> >> After sending my last reply to Gordon, I noticed something in your
>> >> wording that I'd now like to double check. When I asked if you tried
>> >> closing the consumer explicitly I meant before closing the session
>> >> object, i.e:
>> >> consumer.close();
>> >> session.close();
>> >>
>> >> Can you confirm that is what you updated your code to do?
>> >>
>> >> > Setting the prefetch value to 1 didn't help as the next message comes
>> to
>> >> > the consumer immediately after receive(). So, there could be 0 or 1
>> >> locked
>> >> > messages after each consumer.
>> >> >
>> >> > Setting the prefetch value to 0 brings me back to the drain problem:
>> >> > Service Bus doesn't answer anything after the sent packet with
>> >> 'drain=true'
>> >> > , so receive() is blocked forever. However, there are some (probably
>> >> empty)
>> >> > AMQP packets sent after some time, but Qpid doesn't send anything
>> >> anymore.
>> >> >
>> >> >
>> >> > On Tue, Jun 28, 2016 at 6:34 PM, Robbie Gemmell <
>> >> robbie.gemmell@gmail.com>
>> >> > wrote:
>> >> >
>> >> >> On 28 June 2016 at 17:00, Dale Green <gr...@gmail.com>
>> wrote:
>> >> >> > Hi people,
>> >> >> >
>> >> >> > I have a problem using Qpid JMS 0.9 with Service Bus.
>> >> >> >
>> >> >> > The use case is the following:
>> >> >> > I want to create a connection, session, and a queue consumer and
>> >> receive
>> >> >> 0
>> >> >> > or 1 messages within a given timeout. That is, receive(timeout) is
>> >> called
>> >> >> > only once. Immediately after that, the session and the connection
>> are
>> >> >> > closed.
>> >> >> >
>> >> >> > The problem is:
>> >> >> > The consumer may receive multiple messages during its lifetime
>> (which
>> >> the
>> >> >> > client code doesn't even see, because receive is called only once).
>> >> For
>> >> >> > Service Bus, all this means peek-and-lock, so the messages that
>> were
>> >> sent
>> >> >> > to the Qpid client are locked for the time set in the "Lock
>> Duration"
>> >> >> > property of the queue (default value is 30s/60s, Azure/Windows),
>> and
>> >> >> > therefore they are unavailable for other Qpid consumers for a
>> certain
>> >> >> > period of time. I would expect that something like the method
>> >> Abandon()
>> >> >> > from the C# API should happen on session close.
>> >> >> >
>> >> >> > So:
>> >> >> > Is this a bug, feature, or I need to configure/call something in a
>> >> >> > different way?
>> >> >> >
>> >> >> > Thanks!
>> >> >>
>> >> >> My guess is that ServiceBus is not taking the consumers implicit
>> >> >> detachment when the session ends as reason to release the messages.
>> >> >> Perhaps try explicitly closing the MessageConsumer (I'm taking your
>> >> >> text above literally, such that you arent doing so currently) to see
>> >> >> if that prods it into doing so?
>> >> >>
>> >> >> Another thing you could to help is if you know you want at most 1
>> >> >> message is to only give 1 message credit at a time (setting the
>> >> >> prefetch config to 1 or 0...though the earlier server issue you ran
>> >> >> into around 'drain' behaviour may mean this doesnt work so well)
>> >> >>
>> >> >> Robbie
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org