related to https://jira.jboss.org/jira/browse/HORNETQ-50.
As I understand it, the idea behind the JIRA issue is to make receiveImmediate() "smarter" by checking the client buffer *and* if there are messages in transit or waiting to be delivered on the server before returning a null message.
This would be an alternative to receive() which blocks indefinitely or receive(timeout) which must be looped.
However, this approach would not work when the consumer is a browser. A "browser" client consumer does not track its delivering refs and does not acknowledge its messages. This means that the server-side part of the browser does not know if there are any delivering messages.
A smarter implementation of receiveImmediate is useful for regular core consumers.
In that case, if the client buffer is empty, we asks the server if there are delivering messages in transit. If that's the case, we loop again on the client buffer until the message is delivered.
It does not make sense to have server-side browsers track delivery or acks.
One approach would be to ask the BrowserDeliverer's iterator if there is a next message.
The client browser would then know that it can wait to have at least another message delivered to the client buffer
Implementing this version of receiveImmediate() would add another packet to our wireformat handled by the ServerSessionPacket and delegated to the ServerConsumer.
If the server consumer is read only (aka a browser), we ask the browser deliverer if there is a next message in its iterator, else we check that the deliveringRefs > 0.
When the client receives the packet response, either there is no other message coming and it returns null. Otherwise, we loop again in the client buffer waiting for at least one message to be eventually delivered.