[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-users
Subject:    Re: Advisory Topic
From:       Daniel Israel <disrael () liveops ! com>
Date:       2015-09-23 19:25:05
Message-ID: 117FA0C1-DF6F-4583-9BE4-CE142B306CC0 () liveops ! com
[Download RAW message or body]


Thanks for the update Tim.  I have a scheduled update to 5.11.1.  Supposed to go to \
production this week.

Once there, as you've advised, we'll be in a better place to diagnose the problem.

Thanks.



On 9/23/15, 6:13 AM, "tbain98@gmail.com on behalf of Tim Bain" <tbain98@gmail.com on \
behalf of tbain@alumni.duke.edu> wrote:

> That's definitely possible, if either selectors are in use or the messages
> were all sent before any consumer subscribed.  EnqueueCount and
> DequeueCount aren't very useful for topics; instead, you need to check the
> EnqueueCount and DequeueCount on each individual subscription on the topic,
> and for that I always use JMX.  That will eliminate the "messages sent
> before the consumer subscribed" factor (because by definition, the
> subscription only gets those messages sent after it was created), and using
> JMX lets you look at other attributes such as how many messages have been
> dispatched, whether a selector is in use, etc.
> 
> Many, many people run networks of brokers without the advisory messages
> running them out of memory, so it's unlikely that that's your problem.  So
> if you see any subscription with messages that have been dispatched but are
> not acknowledged, that's a cause for concern; otherwise, this "theory"
> isn't your problem and you should focus your attention elsewhere.
> 
> With that being said, if you're still on the pre-5.3.0 broker you were on a
> month ago, all bets are off (and JMX might or might not expose the
> attributes I mentioned).  If you did the upgrade (I sure hope you did, or
> that you have one scheduled in the very near future), what version are we
> talking about?
> 
> Tim
> 
> On Tue, Sep 22, 2015 at 9:37 AM, Daniel Israel <disrael@liveops.com> wrote:
> 
> > 
> > We are running a network of brokers, but I'm tracking down a memory issue
> > and one of the "theories" is that messages sent to Advisory topics is not
> > being freed because we see [sometimes very large] numbers of messages
> > enqueued, no messages dequeued, and a non-zero number of consumers.  Is
> > that something that's possible?
> > 
> > 
> > 
> > 
> > On 9/21/15, 8:46 PM, "tbain98@gmail.com on behalf of Tim Bain" <
> > tbain98@gmail.com on behalf of tbain@alumni.duke.edu> wrote:
> > 
> > > This is the first search result when I Google for 'activemq advisory':
> > > http://activemq.apache.org/advisory-message.html
> > > 
> > > If you're not trying to explicitly use advisory topics yourself, you can
> > > ignore them; brokers in a network of brokers use them to figure out where
> > > consumers are, but you don't have to do anything with them.  If you're not
> > > running a network of brokers, you'll get a small performance boost by
> > > turning them off, as described on the page I linked.  Note that it's a
> > > small benefit and that you'll have to remember to undo the change if you
> > > ever move to a network of brokers topology; consider whether it's worth
> > the
> > > effort for your use case.
> > > 
> > > On Mon, Sep 21, 2015 at 4:44 PM, Daniel Israel <disrael@liveops.com>
> > wrote:
> > > 
> > > > I see a large number of advisory topics (ActiveMQ.Advisory.*) in my list
> > > > of topics, such as:
> > > > 
> > > > ActiveMQ.Advisory.TempQueue
> > > > 
> > > > 
> > > > What are these used for?  Is it a problem if these Topics have consumers
> > > > and none of the messages are dequeued?
> > > > 
> > > > Thanks for any help.
> > > > 
> > 


["smime.p7s" (application/pkcs7-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]