[
https://issues.apache.org/jira/browse/AMQ-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14746425#comment-14746425
]
Ben O'Day commented on AMQ-5942:
--------------------------------
[~cshannon] - if these were simply performance issues, then I'd agree...improve
the docs and recommend alternate configs. but, this factory completely breaks
the message group algorithm under common scenarios w/o any indication...even
the stock quote example on the message group feature page would exceed 1024
groups and break.
overall, this is a bug because the factory does NOT guarantee single threaded
processing or dispatch ordering by JMSXGroupId...the primary reasons to use
message groups. the fact that workarounds exist doesn't excuse the
implementation...the runtime should prevent using a feature that simply won't
do what its designed to under higher volume scenarios.
> 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)
