You are using receive with a timeout. Paging eventually needs time to process reading and delivering you the message.
I will run your test here real quick.. give some time.
Thanks Clebert. It seems that once it gets in this state, calling without a timeout will never return.
I could replicate the issue here. I will have to look on this early next week.
Can you open a JIRA please?
One thing weird here. is the sizes you are using. 2048 versus 1024.
did you try bigger sizes with a more accurate example?
I know what this is...
you are consuming and generating messages using transactions.
You could eventually be starving... like you are not committing enough acks (as you are running multi-consumers) hence you won't be freeing space to depage more data.
You should play with better margins.
I will still take another look early next week to make sure about this. I have been running your test with 10k max versus 1K page size and it seems ok so far.
So, you are actually abusing it in some way. I'm not sure if you have a better reason (like trying to replicate another issue you had or something), or if this is actually what you did in production.
I made the settings small to make sure I was paging, as it seemed to be related to that.
The real life example uses this as the address settings:
We have encountered this behavior twice so far in real-world testing. We have a relatively small max-size-bytes because we may eventually have thousands of queues running on a single server. If you can recommend better configuration options, that would be the best case scenario.
ok... can you open the JIRA?
I will work on it on tuesday. (after the US holiday)
BTW: Nice and easy packaging on your test. Thank you for that.
People either submitting easy tests like this (or even UnitTests that are easy to run on eclipse) will always get better attention, not only because we want to favour such behaviour, but also because we replicate issues within minutes and we can dedicate our time on fixing them.
Thanks for the packaging. This is really a nice example on how to do it for other users.
It's a valid testcase that I'm fixing.. but the issue wouldn't happen if I always reused the same consumer.
(It's a common anti-pattern on spring integration though.. just you know...
if you create / close a consumer on every message you receive.. you're not doing much of async message receiving... you are basically doing a round trip every time you create a consumer...
worse you are also trashing a bunch of messages that were cached on your client and will make them to be re-sent.. it's really bad for performance)
I'm still going to fix it... as I also found an issue when consumer-window-size=0 with a single consumer.
Thanks Clebert. The reason I don't maintain a session/consumer is because there are thousands of queues and work needs to occur in batches. These batches necessitate separate transactions, which does not seem to map well to maintaining a single session and consumer.
Well.. ok.. it's up to you...
You would get better performance if you could keep your consumer up and do the transaction some other way.
I don't know your architecture.. so it's hard for me to opine. You just need to be aware of the round-trip that will happen on session.createconsumer and consumer.close();
You probably need to at least disable client-buffering by setting consumer-window-size=0, but you will need to do that after my fix since I'm fixing it.