activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Gale <paul.n.g...@gmail.com>
Subject Re: Configuring limits for advisory topics
Date Thu, 09 May 2013 18:59:25 GMT
>If you subscribe, the advisory broker will replay advisories for
destinations, consumers, etc that exist, but the messages aren't retained.

Perhaps I'm getting hung up on the distinction between 'replay' and
'retain.'  If the broker 'will replay advisories for destinations,
consumers that exist' what is it 'replaying' if not 'retained' advisory
messages? It cannot replay something it does not possess. Confused.


Thanks,
Paul

On Thu, May 9, 2013 at 2:28 PM, Christian Posta
<christian.posta@gmail.com>wrote:

> Nope. messages aren't retained. If you subscribe, the advisory broker will
> replay advisories for destinations, consumers, etc that exist, but the
> messages aren't retained. If there are no consumers, the messages are
> discarded.
>
>
> On Thu, May 9, 2013 at 11:24 AM, Paul Gale <paul.n.gale@gmail.com> wrote:
>
> > There are no subscriptions to the advisory topics at present. Even with
> no
> > subscriptions it was my understanding that these messages would
> accumulate
> > in memory (or disk) unless consumed. It was this accumulation that I was
> > hoping to control. I was under the impression that advisory topics were
> > treated differently than regular topics, where messages are discarded
> > unless someone has subscribed. Is that not true?
> >
> > I have turned on advisory support 'just in case' someone wants to examine
> > said messages. If these advisory messages are being discarded then I
> guess
> > I have nothing to worry about. What is the actual case?
> >
> > Is there any point in specifying a memoryLimit either?
> >
> > Thanks,
> > Paul
> >
> >
> > On Thu, May 9, 2013 at 12:23 PM, Christian Posta
> > <christian.posta@gmail.com>wrote:
> >
> > > May want to check the size of topic subscriptions... the enqueue
> counter
> > > for a topic will always increase as messages are passed to the topic...
> > the
> > > subs are what hold on to the messages and the pending message limit
> > applies
> > > to them.
> > >
> > >
> > > On Thu, May 9, 2013 at 7:17 AM, Paul Gale <paul.n.gale@gmail.com>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > I am trying to configure the use of my advisory topics. Ideally I
> want
> > to
> > > > have them retain advisory messages by time, e.g., 3 days worth, where
> > if
> > > > not consumed within that time frame they are purged. This is to
> prevent
> > > > build up of advisory messages. However, I cannot see a way to specify
> > the
> > > > limit to be time based.
> > > >
> > > > As an experiment I tried the following config (with the limit
> > > deliberately
> > > > set very low):
> > > >
> > > >           <policyEntry topic="ActiveMQ.Advisory.>"
> > > >                        memoryLimit="2mb"
> > > >                        gcInactiveDestinations="false">
> > > >             <pendingMessageLimitStrategy>
> > > >               <constantPendingMessageLimitStrategy limit="10"/>
> > > >             </pendingMessageLimitStrategy>
> > > >           </policyEntry>
> > > >
> > > >
> > > > It's not working. From looking at the web console it's clear that
> some
> > > > advisory topics go past the configured limit of 10 as the enqueued
> > count
> > > > keeps climbing.
> > > >
> > > > Is the memory limit taking precedence over the pending message limit
> > > > strategy or is the enqueued count misleading and not reliable?
> > > >
> > > > If this is not the right way to approach this problem please advise
> on
> > > what
> > > > would be the optimal configuration.
> > > >
> > > > FTW: the systemUsage is configured as follows:
> > > >
> > > >     <systemUsage>
> > > >       <systemUsage>
> > > >         <memoryUsage>
> > > >           <memoryUsage limit="50m"/>
> > > >         </memoryUsage>
> > > >         <storeUsage>
> > > >           <storeUsage limit="50m"/>
> > > >         </storeUsage>
> > > >         <tempUsage>
> > > >           <tempUsage limit="50m"/>
> > > >         </tempUsage>
> > > >       </systemUsage>
> > > >     </systemUsage>
> > > >
> > > > Thanks,
> > > > Paul
> > > >
> > >
> > >
> > >
> > > --
> > > *Christian Posta*
> > > http://www.christianposta.com/blog
> > > twitter: @christianposta
> > >
> >
>
>
>
> --
> *Christian Posta*
> http://www.christianposta.com/blog
> twitter: @christianposta
>

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