[
https://issues.apache.org/jira/browse/AMQ-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved AMQ-3288.
-----------------------------
Resolution: Fixed
Fix in http://svn.apache.org/viewvc?view=revision&revision=1095352
Delay caused by store recovery ignoring batch size on a priority boundary, thus
being limited only by memory resources.
Encountered some additional problems related to out-of-order delivery and
missed messages with immediatePriorityDispatch on memory boundaries. In
addition, some over eager cleanup when priority and non priority destinations
are mixed. All of these are now fixed.
> JDBC persistence adapter, intermittent performance degradation when a durable
> subscriber of priority messages falls behind
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-3288
> URL: https://issues.apache.org/jira/browse/AMQ-3288
> Project: ActiveMQ
> Issue Type: Bug
> Components: Message Store
> Affects Versions: 5.5.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Labels: delay, durable, jdbc, priority
> Fix For: 5.6.0
>
>
> Scenario: Messages are produced with rolling priority - jmsPriority =
> sendCount%10 so there are always high priority messages in the mix.
> One durable client attempting to catch up when being behind by 100k messages.
> Symptom: About the time the priority of messages being consumed switched from
> 9, to 8, the delay happened. Why it was happening, the log scrolled very fast
> with the percentage of memory use change debug command. Delivery was
> suspended.
> This happened for about a minute or so. During this time, one cleanup timer
> tripped, there wasn't any delay for the cleanup sql.
> It was strange, before the delay, the warning about memory stayed around 100%
> or so, but during the delay, it jumped up to 4000%.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
