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
