[
https://issues.apache.org/jira/browse/AMQ-7070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646627#comment-16646627
]
Gary Tully edited comment on AMQ-7070 at 10/11/18 4:56 PM:
-----------------------------------------------------------
Hi Gary! Thanks again! :D
{quote}the tricky bit is knowing where in the store to start reading from
again. The existing logic around setBatch works in the knowledge that the
cursor add order is the same as the store sequence id. Ie: it is a linear
representation of the store order with the caveat that some writes are pending.
Priority skewes that, but care needs to be taken to ensure the setBatch call is
inclusive, but not overly so.
{quote}
So, we already have a problem calling setBatch(candidate) with wrong message as
the order can be different from the order in the store when messages has
priority? Maybe I din't understand this correctly...
- gtully: the problem is that there are low priority message in the cache,
but they are in the right order of w.r.t the queue as the broker sees it.
I thought that if I can call setBatch with messages that are stored after the
"last" (candidate message), it would be safe to call with last (which is the
last message dispatched)... I'm not getting any warning about duplicated
messages.
- gtully: you won't get duplicates, but you may not get all of your purged
messages back again.
was (Author: alanprot):
Hi Gary! Thanks again! :D
{quote}the tricky bit is knowing where in the store to start reading from
again. The existing logic around setBatch works in the knowledge that the
cursor add order is the same as the store sequence id. Ie: it is a linear
representation of the store order with the caveat that some writes are pending.
Priority skewes that, but care needs to be taken to ensure the setBatch call is
inclusive, but not overly so.
{quote}
So, we already have a problem calling setBatch(candidate) with wrong message as
the order can be different from the order in the store when messages has
priority? Maybe I din't understand this correctly...
- the problem is that there are low priority message in the cache, but they
are in the right order of w.r.t the queue as the broker sees it.
I thought that if I can call setBatch with messages that are stored after the
"last" (candidate message), it would be safe to call with last (which is the
last message dispatched)... I'm not getting any warning about duplicated
messages.
- you won't get duplicates, but you may not get all of your purged messages
back again.
> Priority is not being respected when the cursor cache flips
> -----------------------------------------------------------
>
> Key: AMQ-7070
> URL: https://issues.apache.org/jira/browse/AMQ-7070
> Project: ActiveMQ
> Issue Type: Test
> Components: Broker
> Reporter: Alan Protasio
> Priority: Minor
> Attachments: AMQ7070Test.java
>
>
> Messages are being dispatched with wrong priority when the cache is flipped.
> See:
> https://github.com/apache/activemq/blob/master/activemq-broker/src/main/java/org/apache/activemq/broker/region/cursors/AbstractStoreCursor.java#L258
> All messages that could get cached in the cursor are dispatched before even
> though massages with higher priority is in the cache.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
