From Miroslav Novak we got this info:

The difference between receiveNoWait() and receive(250) is:

• receiveNoWait() will send packet to server and ask if there is a message in queue which could be delivered to consumer. So it just takes network round trip time to ask server: "do you have a message for me?" and if there is one then it's sent to client and it's returned from receiveNoWait() call
• receive(250) is very similar but first it waits 250ms if server send message to client's buffer. If there is a message in client's buffer or server sends it there in 250ms timeout then it's returned. If no message is sent to client's buffer in 250ms timeout then basically the same logic as in receiveNoWait() is called. Client asks server if there is a message for him in the queue.

So it seems that those additional 250ms is the time for you to have good statistics. I don't see why it's important. Maybe in those 250ms a message gets to queue and AbstractJMSMessageConsumer.receiveInTransactionNoWait(...) does not return null (so often).

I can see that AbstractJMSMessageConsumer.receiveInTransactionNoWait(...) can also specify filter/selector. This might have effect as well. As paging is used, HornetQ never goes to page files to check if there is a message which match consumer's selector. It only checks current messages in memory due performance reasons. Loading all paged messages from disk and checking if there is one message matching consumer's selector would be big performance problem. So if some messages are consumed from server and memory for queue is freed (it's configurable by max-size-bytes in address-settings - default is 10MB) then next paged file/messages can be loaded to memory.

Do you think something from this might affect you case?