[jira] [Comment Edited] (AMQ-7070) Priority is not being respected when the cursor cache flips

["Gary Tully (JIRA)" <ji...@apache.org>]

    [ 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:55 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... 

   -  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.


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... 

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.

 

> 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)