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
>
>
