[jira] Created: (AMQ-2468) OOM when using JMX purge on a Queue with lots of messages in it

OOM when using JMX purge on a Queue with lots of messages in it
---------------------------------------------------------------

                 Key: AMQ-2468
                 URL: https://issues.apache.org/activemq/browse/AMQ-2468
             Project: ActiveMQ
          Issue Type: Bug
          Components: Broker
    Affects Versions: 5.3.0
            Reporter: Gary Tully
            Assignee: Gary Tully
             Fix For: 5.4.0


the problem is worse when there is a slow consumer and steady producer in the mix.
Problem is that purge forces a page in and a dispatch but the dispatch ends up appending to pagedInPending which is not limited and not bound by the usage metrics so it only appears as an OOM.
Fixing purge to not dispatch helps but the presence of a consumer incurs a dispatch on message sending so over time a steady producer will give the same behavior.
Purge is a special case that highlights the problem of no restriction on pagedInPending with a very slow consumer. If consumers can keep up, or if producer flow control is used, or lazyDispatch, this issue can be avoided.


--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/activemq/browse/AMQ-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Tully updated AMQ-2468:
----------------------------

    Summary: Calling purge on a large queue causes OutOfMemoryError in the broker.  (was: OOM when using JMX purge on a Queue with lots of messages in it)

> Calling purge on a large queue causes OutOfMemoryError in the broker.
> ---------------------------------------------------------------------
>
>                 Key: AMQ-2468
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2468
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.3.0
>            Reporter: Gary Tully
>            Assignee: Gary Tully
>             Fix For: 5.4.0
>
>
> the problem is worse when there is a slow consumer and steady producer in the mix.
> Problem is that purge forces a page in and a dispatch but the dispatch ends up appending to pagedInPending which is not limited and not bound by the usage metrics so it only appears as an OOM.
> Fixing purge to not dispatch helps but the presence of a consumer incurs a dispatch on message sending so over time a steady producer will give the same behavior.
> Purge is a special case that highlights the problem of no restriction on pagedInPending with a very slow consumer. If consumers can keep up, or if producer flow control is used, or lazyDispatch, this issue can be avoided.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/activemq/browse/AMQ-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Tully resolved AMQ-2468.
-----------------------------

    Resolution: Fixed

resolved in r831258.
pagedInPendingDispatch is now limited to maxPageSize.  Now we bypass dispatch for jmx queue modifications like purge and remove matching messages so they are not limited by pending messages and can page through all available messages.
Note: consumers with sparse selectors may now need to increase maxPageSize as ever increasing pagedInPendingDispatch was exceeding that limit in error

> Calling purge on a large queue causes OutOfMemoryError in the broker.
> ---------------------------------------------------------------------
>
>                 Key: AMQ-2468
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2468
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.3.0
>            Reporter: Gary Tully
>            Assignee: Gary Tully
>             Fix For: 5.4.0
>
>
> the problem is worse when there is a slow consumer and steady producer in the mix.
> Problem is that purge forces a page in and a dispatch but the dispatch ends up appending to pagedInPending which is not limited and not bound by the usage metrics so it only appears as an OOM.
> Fixing purge to not dispatch helps but the presence of a consumer incurs a dispatch on message sending so over time a steady producer will give the same behavior.
> Purge is a special case that highlights the problem of no restriction on pagedInPending with a very slow consumer. If consumers can keep up, or if producer flow control is used, or lazyDispatch, this issue can be avoided.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.