messages are probably being delivered before you send the newest priority.. meaning you were too late.
Try setting up consumerWindowSize to 0 on your connection. maybe you won't pre-fetching and having a better behaviour for what you need.. but it won't be as fast... but maybe that's what you needed.
Thank you for your response, Clebert. But i am not sure if this is the problem. In my application, i do like this to test if priority works: first deplay an app which sends thousands of m1, m2, m3 into queue, but there is no MDB (consumers) in ths app. Then undeploy this app, and deploy another app which only has MDB (consumers), then see the log how msg consumed. SO i am pretty sure when there is consumers, all msg are already in the queue.
But i also think maybe it is a problem related with consumerWindowSize, like msg are allocated first and send to buffer before consumed. I will try with consumerWindowSize = 0. Is there sth else you suggest?
Notice that with MDBs you will have many consumers running it in parallel unless you set the number of consumers to 1.. I forgot th parameter now but that's easy to check (I think).. if not please let me know.
Also: with priorities we do our best to work on priorities. It doesn't work well with paging.. as we do it as we depage.
If not: if you set consumerWndowSinze=0 on the RA it should work... but that will make your application go slower. Usually you don't really need strict priority as we try our best. if something is already on the buffer it will probably be consumed earlier anyways.
Also: try the latest version.
Hi Clebert, I tried with your proposal, it works!!! Either set maxSession as 0 or set consumerWIndowSize as 0, it works. Great! Thank you very much!
Btw, one additional question, when i set maxSession as 15 (default one),but i always see only 3 threads consuming msg, is there some way to increase # of threads?
You would probably need to block for some time in order to see threads on a Thread dump. Try adding a small sleep to see if you see many threads blocking. otherwise it may be consuming too fast and you're not being able to see it on the thread dumps?
If that's not the case... you should double check the configs.
and if that still not the case.. let me know what happened.
BTW: one thing we all agree as messaging developers (I had a talk even with ActiveMQ guys... and eventually with Sun Open MQ guys)... Object message is slow (it will use serialization, and a lot of refactoring because of that.. very verbose protocol), and you will be always stuck in Java.
In a near future we are planning to support more clients and any other client outside of Java won't ever be able to read these messages.. keep that in mind.
Actually, i log when onMessage method called in MDB, then i see threads handling each msg, always 3 threads. But yes, the msgs are consumed very fast, but still it is 6500 msg in the queue when i deploy MDB. Regarding objectmsg, yes, i would like to change, that's some legacy code:(