activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: AbstractRegion.addSubscriptionsForDestination … performance.
Date Wed, 03 Jun 2015 13:42:39 GMT
Relevant code:

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

I submitted to capture this.


On Tue, Jun 2, 2015 at 5:15 PM, Kevin Burton <> wrote:

> Here’s another issue I found..
> 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
> Location: *San Francisco, CA*
> blog:
> … or check out my Google+ profile
> <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message