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
