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 <robbie.gemm...@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 <green.dale1...@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.gemm...@gmail.com>
> > wrote:
> >
> >> On 29 June 2016 at 11:08, Dale Green <green.dale1...@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.gemm...@gmail.com>
> >> > wrote:
> >> >
> >> >> On 28 June 2016 at 17:00, Dale Green <green.dale1...@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-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
>
>
