This might be another thread, but I’m wondering if we shouldn’t recommend that other ActiveMQ users enable continuous profiling, at least for one restart of their queue, and capture say a 30 minute sample from their production usage.
This might help identify performance issues that OTHER people are seeing. This might yield some significant performance improvements. It also might identify performance issues which apply to others, and not just *our* setup. On Wed, Jun 3, 2015 at 6:42 AM, Tim Bain <tb...@alumni.duke.edu> wrote: > Relevant code: > > http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-broker/5.11.1/org/apache/activemq/broker/region/AbstractRegion.java#AbstractRegion.addSubscriptionsForDestination%28org.apache.activemq.broker.ConnectionContext%2Corg.apache.activemq.broker.region.Destination%29 > > I think the scenario where this is used is if a destination is being > auto-created on the broker when the first message is sent to it, where > we're looking for consumers who've already registered an interest in that > destination, whereas I think you're thinking of the situation where a > consumer initially registers a subscription. This appears to be done to > allow subscriptions that use wildcards (see the subclasses of > DestinationFilter: > > http://activemq.apache.org/maven/5.11.0/apidocs/org/apache/activemq/broker/region/DestinationFilter.html > , > most of which deal with wildcards or composite destinations). > > I have to think that there are probably ways to speed up the question of > which consumers are going to match a new destination. For example, maybe > we could keep separate lists of subscriptions that use > SimpleDestinationFilters (which should always have matched their > destination when the subscription was created, so they don't need to be > considered when new destinations are created) and of subscriptions that use > other DestinationFilter subtypes (which might match new destinations after > the fact) and only iterate through the latter list. If there's a risk that > a destination for a SimpleDestinationFilter might not actually have been > created ahead of time, then we can use a Multimap<String, Subscription> for > the ones that use SimpleDestinationFilters, making it O(1) to find only the > ones that match a given name, but I'd hope we don't even need to do that. > Does anyone see any problems with that approach that I might not be aware > of? > > I submitted https://issues.apache.org/jira/browse/AMQ-5823 to capture > this. > > Tim > > On Tue, Jun 2, 2015 at 5:15 PM, Kevin Burton <bur...@spinn3r.com> wrote: > > > Here’s another issue I found.. > > > > http://i.imgur.com/EeBNiJK.png > > > > Im trying to figure out why this is needed. Shouldn’t each consumer add > > themselves as a subscription? > > > > At least in our situation, it seems like ActiveMQ could be 60% faster. > > > > > > > > -- > > > > Founder/CEO Spinn3r.com > > Location: *San Francisco, CA* > > blog: http://burtonator.wordpress.com > > … or check out my Google+ profile > > <https://plus.google.com/102718274791889610666/posts> > > > -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile <https://plus.google.com/102718274791889610666/posts>
