Hi Robbie, Thank you! Adding &jms.receiveLocalOnly=true to the connection string fixed the problem.
As far as I understand, this options can lead to a situation when receive(timeout) returns null (because of an empty local buffer), but actually there is a message on the queue. Under what circumstances can this happen? Thanks! On Wed, Jun 22, 2016 at 11:16 AM, Robbie Gemmell <[email protected]> wrote: > The only case we have seen this is where the server fails to respond > as expected to the consumers attempt to drain its link credit when a > receive expires without a message being available. The 0.10.0 client > release adds a timeout that will close the consumer if this arises. > > If you add the "jms.receiveLocalOnly=true" option+value (from > > http://qpid.apache.org/releases/qpid-jms-0.9.0/docs/index.html#jms-configuration-options > ) > to your connection URI it will configure the consumer to work out of > its local buffer without draining the link when nothing arrives. If > that helps, that would indicate the above is likely correct, but > looking at the protocol trace logging might confirm, see the bottom of > http://qpid.apache.org/releases/qpid-jms-0.9.0/docs/index.html#logging > for details of hwo to enable it. > > Robbie > > On 22 June 2016 at 10:00, Dale Green <[email protected]> wrote: > > Hi, > > > > I am trying to communicate with Service Bus for Windows Server via AMQP > and > > found this problem. > > > > This was tried with Qpid JMS 0.9.0 and also with the latest snapshot. If > > there are no messages on the queue when I call receive(timeout>0), the > call > > blocks forever. Sending a message to the same queue after the call does > not > > help either. > > > > Here is the stack trace: > > > > Unsafe.park(boolean, long) line: not available [native method] > > LockSupport.park(Object) line: 186 > > CountDownLatch$Sync(AbstractQueuedSynchronizer).parkAndCheckInterrupt() > > line: 834 > > > CountDownLatch$Sync(AbstractQueuedSynchronizer).doAcquireSharedInterruptibly(int) > > line: 994 > > > CountDownLatch$Sync(AbstractQueuedSynchronizer).acquireSharedInterruptibly(int) > > line: 1303 > > CountDownLatch.await() line: 236 > > ProviderFuture.sync() line: 97 > > JmsConnection.pull(JmsConsumerId, long, ProviderSynchronization) line: > > 766 > > JmsConnection.pull(JmsConsumerId, long) line: 755 > > JmsMessageConsumer.performPullIfRequired(long, boolean) line: 631 > > JmsMessageConsumer.dequeue(long, boolean) line: 263 > > JmsMessageConsumer.receive(long) line: 196 > > Receiver.main(String[]) line: 80 > > > > I used the Receiver class in the included examples. The connection string > > is: > > amqps://x.x.x.x:5671/?transport.verifyHost=false&amqp.idleTimeout=121000 > > > > I am setting this timeout, because Service Bus wants >=60 s timeout in > AMQP > > OPEN. > > > > And just as reference, these combinations I already tried and > > receive(timeout) returns null as expected: > > - Qpid JMS 0.9.0 against AMQP ActiveMQ > > - Qpid 0.32 (amqp-1-0-client) against AMQP ActiveMQ > > - Qpid 0.32 (amqp-1-0-client) against AMQP Service Bus > > > > So, is it a bug or I am missing something? > > > > Thanks! > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
