activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Bain (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-4666) Topic persistent message publishing is blocked by hitting 100% of per-destination memory limit if there's any durable subscriber connected but not consuming.
Date Sun, 11 Jan 2015 05:29:36 GMT

    [ https://issues.apache.org/jira/browse/AMQ-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14272816#comment-14272816
] 

Tim Bain commented on AMQ-4666:
-------------------------------

I overlooked your statement that you're using persistent messages; sorry about that.

Torsten's comment on Christian's post at http://www.christianposta.com/blog/?p=273 gives a
detailed description of why you're seeing this, and of two work-arounds available to you (disabling
per-destination memory limits and setting cursorMemoryHighWaterMark to a percentage that is
less than the ratio of the per-destination memory limit to the entire-broker memory limit.
 Hopefully one of those options is workable for you.

Both Christian's blog post and Torsten's comments make it clear that this is known and expected
behavior.  That's not to say that that's the best possible way for it to work, or that the
change you're requesting shouldn't be implemented; I think that it should, as long as the
people who know this code well can assure themselves that it doesn't mess up anything else.
 But it makes this an Improvement, not a Bug, so you should change the issue type to Improvement.

If you want it to have the best chance of getting implemented, I'd recommend you reword the
title and description to focus on the improvement to be made, not the unwanted behavior that
results from not making the change.  It also sounds like you're proposing changing the implementation
of AbstractPendingMessageCursor.hasSpace(); is that right?  Since you have an implementation
in mind, I'd encourage you to create and attach the patch you're proposing; an already-implemented
patch is going to be the most likely to get implemented because it's the least work for whoever
might take this on.

> Topic persistent message publishing is blocked by hitting 100% of per-destination memory
limit if there's any durable subscriber connected but not consuming.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-4666
>                 URL: https://issues.apache.org/jira/browse/AMQ-4666
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.7.0
>            Reporter: Jaewoong Choi
>         Attachments: MemoryLimitTest.java
>
>
> Failing scenario:
> 1. Embedded broker starts with the following configurations:
>    - persistent = true,
>    - systemUsage.memoryUsage.limit = 10*1024*1024 // 10mb broker main memory limit
>    - destinationPolicy.policyEntry.memoryLimit = 1*1024*1024 // 1mb per-destination memory
limit
> 2. Create a topic durable subscription with prefetchLimit=0.
> 3. Create a topic publisher and publish persistent 400kb messages.
> 4. (Problem) After publishing 3 messages successfully, PFC kicks in and the above topic
publisher gets blocked its publishing.
> At step #4, the expectation is not seeing any publisher blocking for the persistent message
publishing until the store limit is reached.  How come the persistent message publishing is
limited by 100% memory full?
> Per the code inspection, this is because the store cursor of the topic durable subscriber
(i.e. TopicStorePrefetch) is working with the main broker's memory limit, not with the per-destination
memory limit.  Hence, it keeps increasing broker main memory usage over the per-destination
memory limit and after it reached 100% of per-destination limit, PFC kicked in.
> I verified that the above scenario went through well if I fix the store cursor to use/refer-to
the per-destination memory usage along with its pending list (cache) management.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message