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).
I thought that could be the case, but just wanted you to check in case the server did something different with the explicit protocol link closure (consumers/producers are not explicitly closed at the protocol level by the client when the session is closed, just implicitly). > 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). > In the case of a long running consumer I believe that is a key purpose of the servers message lock, so that makes sense. The server continuing to lock messages for a consumer that doesnt exist anymore and can never consume them, less so. > 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. > Yep, the 'prefetch 1' was mainly just aimed at reducing the number of locked messages to at most 1, the way to work around the servers behaviour using prefetch config would be the '0 prefetch' but as mentioned your previous thread meant that likely wouldnt work given the other server issue. > 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. > The frames will be heartbeats sent by the server to satisfy the clients requested idle-timeout. If the server hasnt advertised an idle-timeout then the clint wont send it heartbeats in return. The 0.10.0 client release (currently under vote for release in the next few days) will timeout the drain and close the consumer with an error in cases such as this where the server doesnt respond. Given the server behaviours I'm afraid the only thing I can currently think to suggest for now is that you look at not consuming only a single message with each consumer/session/connection, if thats possible for what you are doing (its generally not advised purely for how ineffcient it is relative to a long lived consumer). > > 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
