[
https://issues.apache.org/jira/browse/AMQ-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon closed AMQ-5942.
---------------------------------------
Resolution: Not A Problem
Based on my initial thoughts on this and after discussing this issue with
[~tabish121], I don't think we should change this. We don't want to leave a
potential for unbounded memory usage in the broker. Plus, the current
expectation is that the LRU implementation is the default. We should update
the documentation to describe this so that if someone needs more than 1024
groups they can change the policy configuration to increase the number of
groups or to use a different implementation such as
SimpleMessageGroupMapFactory.
> CachedMessageGroupMapFactory fails with large key sets
> ------------------------------------------------------
>
> Key: AMQ-5942
> URL: https://issues.apache.org/jira/browse/AMQ-5942
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.11.1
> Reporter: Ben O'Day
> Attachments: MessageGroupFactoryRouteTest.java
>
>
> the current default factory is the CachedMessageGroupMapFactory which uses an
> LRUMap with a maxSize of 1024 keys. If you use this with more than 1024 keys
> and fail to explicitly increase the maxSize, then the message groups fails to
> ensure ordering by group, same thread processing by group and overlapping
> execution.
> I have reproduced this behavior in the attached unit test (using Camel routes
> as consumers)...if you switch to the SimpleMessageGroupMapFactory or increase
> the max size of the cache above the number of keys...the issues go away
> two suggestions
> -throw an error when the maxSize is exceeded if using the
> CachedMessageGroupMapFactory
> -make the SimpleMessageGroupMapFactory the default (unlimited)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)