Version 4

    The receiveNoWait() behavior on JBM



    You don't get the same results as per JBossMQ, when receiveNoWait() is used on JBM. The semantics of receiveNoWait() is commonly misunderstood and it doesn't behave the same way as it works with JBossMQ. The receive() calls are now handled on the client side by JBM. Which means they don't go to the server. This includes receiveNoWait(), so it means there is a chance receiveNoWait() returns null after a send to the destination has returned "ok".




    According to the semantics of receiveNoWait() this is expected, receiveNoWait doesn't make any guarantees that it will definitely return a message if send has returned. It also seems that other messaging systems work this way. Though it's possible to make receiveNoWait() go to the server, this is purposely configured as stated for better performance.




    Further reading :



    Note :

    However on HornetQ, this behavior has been changed. Which means, receiveNoWait() fetches messages from the broker.