activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Burton <bur...@spinn3r.com>
Subject Re: Does JMS priority work with “small" maxPageSize ?
Date Wed, 06 May 2015 23:00:56 GMT
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.tully@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 <burton@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>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message