Ouch. OK. I think a lot of these behaviors might need to be documented a bit better, or maybe added as edge cases to be fixed in 6.0. I imagine KahaDB could do this internally but I’m not sure.
I think we might just end up having 2 or 3 queue priorities implemented by using different physical queues. On Wed, May 6, 2015 at 5:10 AM, Gary Tully <gary.tu...@gmail.com> wrote: > that is true, the dispatch goes through the cursors in batches once > memory (or the cursor cache) is exhausted. > For durable subs, there is the ability to bypass the paged in messages, > see: > > https://github.com/apache/activemq/blob/165959e25007271f8cdfdcf72641b9a92483ef40/activemq-unit-tests/src/test/java/org/apache/activemq/store/MessagePriorityTest.java#L83 > > I know folks have asked for something similar for queue cursors. It > would make a nice enhancement but may be tricky to get right. > > On 4 May 2015 at 19:14, Kevin Burton <bur...@spinn3r.com> wrote: > > Let’s say you have a queue with 1M items.. they are all low priority. > Then > > you add a high priority entry. > > > > I believe, due to message cursors, that it won’t be executed until it’s > > read into the “maxPageSize window”. > > > > Is this correct or does it depend on the underlying store? > > > > KahaDB and LevelDB could probably move it to the head (I think) but the > > memory store can not... > > > > -- > > > > Founder/CEO Spinn3r.com > > Location: *San Francisco, CA* > > blog: http://burtonator.wordpress.com > > … or check out my Google+ profile > > <https://plus.google.com/102718274791889610666/posts> > -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile <https://plus.google.com/102718274791889610666/posts>
