I have an application which assigns sequential numbers to messages.  When starting up, it needs to determine the number of the last message written to the queue, and it tries to do this by issuing repeated receiveNoWait() calls until the result is null, and keeping track of the last sequence number seen.  We use CLIENT_ACKNOWLEDGE, and never acknowledge anything so that the messages remain on the queue for later actual processing.  This is done so that when a new message is to be added to the queue, we know whether there is a gap in the sequencing (which would mean that messages are missing).

Originally, I used a QueueBrowser for this, but I found that not all of the messages were returned.  As a workaround, I used the above method, which seemed to work at the time.  However, one of our customers who deals with high message volumes is encountering situations where receiveNoWait() returns null before the end of the queue is reached.  As a workaround for this, I added logic to require 5 consecutive null results before concluding that we've reached the end of the queue, but the entire queue contents are still not being delivered.

Is there some resource limitation that limits the number of messages or amount of message data that a consumer can hold without acknowledgement, causing receiveNoWait() to return null even when additional messages exist on the queue ?  Is there a way to disable this ?  This is currently occurring with WildFly 14.0.0.Final, but has been happening since we originally deployed with WildFly 10.0.0.Final.