You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Ben O'Day (JIRA)" <ji...@apache.org> on 2015/09/15 17:57:45 UTC
[jira] [Updated] (AMQ-5942) CachedMessageGroupMapFactory fails with
large key sets
[ https://issues.apache.org/jira/browse/AMQ-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ben O'Day updated AMQ-5942:
---------------------------
Priority: Major (was: Trivial)
Description:
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...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)
was:
the current default factory is the CachedMessageGroupMapFactory and uses an LRU with a maxSize of 1024 keys by default.
Any reason the SimpleMessageGroupMapFactory can't be the default instead since it doesn't have a size limit and I'd think perform better for the common use cases?
per http://scott.cranton.com/2010/09/activemq-message-groups.html
Issue Type: Bug (was: Improvement)
Summary: CachedMessageGroupMapFactory fails with large key sets (was: make SimpleMessageGroupMapFactory the default)
> 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
>
> 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...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)