Kevin, Messages don't pile up on advisory topics because of the semantics of topics: unless you have a durable subscription (which the broker-to-broker advisory subscriptions aren't, if I recall correctly), any message that arrives on the broker will be delivered to all connected consumers (and not to any disconnected ones), so the only thing that could cause messages to back up is a slow consumer (which I've never observed to happen, though I'm sure it's possible). You could certainly get slow consumers and/or durable subscriptions on advisory topics if you've written custom consumers, just like for any other topic, but that's a separate issue.
I wasn't at all clear why changing the frequency (to "never") of message expiration checks would affect the performance of destination GC operations when the number of queues is large. Is that due to synchronization between those two operations, or thread contention because one or both takes longer than its periodicity to complete so we eventually have more pending threads than the cores can run, or... I'm in favor of the changes as you've described it (I can't think of a reason we'd want advisory messages to expire, though ideally it would be configurable for just in case someone has a need for it that I can't think of; configurable or not, having 0 as the default sounds like a clear win to me), I'm just not clear on how it has the larger effects you describe. Also, can you point me to the O(N^2) code related to Timer.purge()? If it really is purging every queue each time any queue's timer fires, that sounds like incorrect code, but I'd like to see it to make sure I'm not misunderstanding what you're describing. Tim On May 2, 2015 4:34 PM, "Kevin Burton" <[email protected]> wrote: > I’m confused by something. Why don’t messages pile up in advisory topics? > Topics only deliver messages to consumers who are actually listening I > assume? > > On Sat, May 2, 2015 at 2:07 PM, Kevin Burton <[email protected]> wrote: > > > I’m sorry.. this is N^2 because the Timer just keeps growing for every > new > > queue and they need to be purged and it has to evaluate each one. > > > > On Sat, May 2, 2015 at 1:40 PM, Kevin Burton <[email protected]> wrote: > > > >> Also, while this is a small performance boost in my example, this should > >> have a massive impact when running with large queues. It’s calling > >> Timer.purge() on each queue GC and if you have a lot of queues you’re > going > >> to have a lot of TimerTasks so this is a O(N). It also holds a global > lock > >> during this operation so no new queues can be created during a queue GC. > >> > >> On Sat, May 2, 2015 at 12:23 PM, Kevin Burton <[email protected]> > wrote: > >> > >>> I’m doing a bunch of performance analysis of ActiveMQ this weekend to > >>> see if I can improve queue creation and destruction time. The good > news is > >>> that there are a lot of areas of optimization. > >>> > >>> It looks like one is that advisory topics are created with the default > >>> expireMessagesPeriod (which is 30000). However, no advisory messages > are > >>> produced with TTLs. > >>> > >>> I believe this is done in AdvisoryBroker.fireAdvisory > >>> > >>> … looking at this code, a TTL isn’t set. So I think that it would be a > >>> good idea to enable expireMessagesPeriod=0 for advisory topics. > >>> > >>> Here’s the code if you’re interested: > >>> > >>> http://pastebin.com/i3hXDGEW > >>> > >>> Looks like the following policyEntry works as a proof of concept. > >>> > >>> <policyEntry topic=">" > >>> prioritizedMessages="false" > >>> useCache="false" > >>> maxBrowsePageSize="2147483647" > >>> expireMessagesPeriod="0"> > >>> > >>> </policyEntry> > >>> > >>> (I am going to constrain it for advisory topics though). > >>> > >>> In my test time time for GCing all my queues went from 45s to 17s. > It’s > >>> MUCH higher than this under production load though due threading > issues. > >>> > >>> Are there any potential issues I might be missing here? > >>> > >>> If this works I might try to submit a patch to disable > >>> expireMessagesPeriod by default for advisory topics. > >>> > >>> -- > >>> > >>> 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> > >> > >> > > > > > > -- > > > > 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> >
