Mailing-List: contact issues-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Tue, 15 Sep 2015 22:49:46 +0000 (UTC)
From: "Ben O'Day (JIRA)" <jira@apache.org>
To: issues@activemq.apache.org
Message-ID: <JIRA.12858082.1440266493000.348106.1442357386267@Atlassian.JIRA>
In-Reply-To: <JIRA.12858082.1440266493000@Atlassian.JIRA>
References: <JIRA.12858082.1440266493000@Atlassian.JIRA>
 <JIRA.12858082.1440266493463@arcas>
Subject: [jira] [Commented] (AMQ-5942) CachedMessageGroupMapFactory fails
 with large key sets
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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)