JMS ReceiveNowait does not return a message even if the queue is not empty

Details

Description

Description:
The first invocation of receiveNoWait does not return a message even if the queue is full.
How to replicate:
1) create a queue
2) send a message
3) try to consume this message using receiveNoWait
==> we get null even if there is a message seating in the queue
Solution:
When a JMS consumer first invokes receiveNowait then BasicMessageConsumer_0_10 request for more credits and then poll the _synchronousQueue. This does not leave enough time for the message to be enqueued.
One solution would be to query the queue size before allowing the credits: Something like that would work:
public Object getMessageFromQueue(long l) throws InterruptedException
{
long size = 0;
if(l < 0)

According to messageFlush definition:
"Forces the sender to exhaust his credit supply. The sender's credit will always be zero when this command completes.
The command completes when immediately available message data has been transferred, or when the credit supply
is exhausted."
Once the sync ope returns potentially available messages will have been transfered and ready to consume form our local queue synchronousQueue

Arnaud Simon
added a comment - 24/Feb/09 14:48 no, the problem is that we need to know whether messages have been sent to the client after messageFlow returns.
I believe that a way to achieve that is to do something like
_0_10session.getQpidSession().messageFlow(getConsumerTagString(),
MessageCreditUnit.MESSAGE, 1);
_0_10session.getQpidSession().messageFlush();
_0_10session.getQpidSession().sync();
According to messageFlush definition:
"Forces the sender to exhaust his credit supply. The sender's credit will always be zero when this command completes.
The command completes when immediately available message data has been transferred, or when the credit supply
is exhausted."
Once the sync ope returns potentially available messages will have been transfered and ready to consume form our local queue synchronousQueue

Actually we cannot do a take as the message may have been consumed by another consumer
Maybe the solution would just be to poll with a small timeout that would let a chance for the message to be delivered.

Arnaud Simon
added a comment - 04/Feb/09 18:27 Actually we cannot do a take as the message may have been consumed by another consumer
Maybe the solution would just be to poll with a small timeout that would let a chance for the message to be delivered.