Hi, do you get it work? You need comment out the vmcursor in the queue policy and the whole policy for the queue looks like this, <policyEntry queue="YOUR_prioritized_QUEUE_NAME" producerFlowControl="false" prioritizedMessages="true" useCache="false" queuePrefetch="1" expireMessagesPeriod="0"/> I have tested it and it does work but performance penalty becomes arrestive.
At 2013-01-07 22:07:11,"Gary Tully" <[email protected]> wrote: >your important message is in the store, but not in the current memory >snapshot. >Unless we keep all messages in memory (vmcursor), we need to carefully >configure the store cursors use of memory. > >There are two problems here. > >The first is caching messages on send by the store cursor. >If there is a large batch of low priority messages that cause the cache to >be exhausted, followed by some high priority messages, the high priority >messages will only be read and dispatched when the cache is depleted. >Currently it is not possible for a cached low priority message in memory to >be replaced by a high priority message. >The workaround for this is to disable the cursor cache. ><policyEntry queue="xxx" useCache="false" ..> > >The second is paging into memory from the store, to ensure true priority >order this must occur only for dispatch to consumers. By default there is a >periodic message scan to check for priority. This must be disabled, >otherwise a consumer will get a view of the store order as seen by the last >scan rather than at the time it subscribes. > >The workaround for this is to disable async expiry processing: ><policyEntry queue="xxx" useCache="false" expireMessagesPeriod="0" > > >Lastly, if high priory messages are a must have for each consumer, using >prefetch=1 is necessary, such that every consumer dispatch goes to the >store to find the current highest priority message. Otherwise a batch of >priority ordered messages will be in memory ready to dispatch, irrespective >of new deliveries. > ><policyEntry queue="xxx" useCache="false" expireMessagesPeriod="0" >queuePrefetch="1" > > >It is a trade off between taking a snapshot and caching or getting the >latest up-to-date information w.r.t to producers. > >For active durable topic subscribers we support immediate priority >dispatch, where we bypass the cache if we have a higher priority message >and dispatch it immediately to all subscribers. >We may need to investigate a similar arrangement for queues. > > >On 7 January 2013 07:40, xawiers <[email protected]> wrote: > >> According to SuoNayi, amq will respect the message priority order if >> vmcursor >> is used. >> If I will use default cursor - I will not get message priority. And this is >> bad. Message priority is very important to me. >> I have tried with storage cursor also: >> One producer, one consumer >> >> added 10 messages with priority 3 >> added 3 messages with priority 5 >> added 100000 messages with priority 3 >> added 3 messages with priority 5 >> >> consumed 3 messages (all priority 5), consuming 4th message I got message >> with priority 3. Where is my important message ? >> >> >> >> -- >> View this message in context: >> http://activemq.2283324.n4.nabble.com/Message-priority-tp4040260p4661442.html >> Sent from the ActiveMQ - User mailing list archive at Nabble.com. >> > > > >-- >http://redhat.com >http://blog.garytully.com
