[jira] [Resolved] (AMQ-3288) JDBC persistence adapter, intermittent performance degradation when a durable subscriber of priority messages falls behind

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

     [ 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