On 05/09/2013 02:59 PM, Paul Gale wrote:
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.
The replay is based on state, each destination, consumer, producer etch that the broker knows about at the time the client connects a new advisory message is generated. If no consumer is subscribed to the target advisory topic the messages is dropped. The word Topic is your key here, a topic doesn't retain anything when no consumers are present.




Thanks,
Paul

On Thu, May 9, 2013 at 2:28 PM, Christian Posta
<christian.po...@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.g...@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.po...@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.g...@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



--
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.b...@redhat.com | www.fusesource.com | www.redhat.com
skype: tabish121 | twitter: @tabish121
blog: http://timbish.blogspot.com/

Reply via email to