Dare I ask - would this be something useful to enable in shipping activemq.xml configuration files?
Just a quick Googling leads me to believe each unused destination requires AMQ to maintain a destination thread each of which requires RAM and overhead... James On 16 June 2011 14:34, Dejan Bosanac <de...@nighttale.net> wrote: > Yes, the inactivity means that there's 0 messages for some time and there > are no new producers/consumers added > > > Regards > -- > Dejan Bosanac - http://twitter.com/dejanb > ----------------- > The experts in open source integration and messaging - > http://fusesource.com > ActiveMQ in Action - http://www.manning.com/snyder/ > Blog - http://www.nighttale.net > > > On Thu, Jun 16, 2011 at 2:45 PM, James Green <james.mk.gr...@gmail.com > >wrote: > > > Now that's helpful... Let me just confirm my understanding: > > > > schedulePeriodForDestinationPurge="10000" > > > > Is telling the broker to delete inactive destinations every ten seconds? > > > > gcInactiveDestinations="true" inactiveTimoutBeforeGC="30000" > > > > Is expressing that the policyEntry should be garbage collected and should > > be > > considered garbase if inactive for 30 seconds or more? > > > > There's no definition of what precisely constitutes activity on that > page. > > Allow me to suggest: > > > > 1. A subscription to that destination > > 2. A send to that destination > > 3. A message being present on that destination > > > > How far off am I? I assume that a destination includes both queues and > > topics? > > > > Thanks, > > > > James > > > > On 16 June 2011 09:04, Martin C. <mart...@gmx.at> wrote: > > > > > Hi, > > > > > > Have a look at > > > http://activemq.apache.org/delete-inactive-destinations.html > > > This might be what you want. > > > > > > Best regards, > > > Martin > > > > > > On Wed, Jun 15, 2011 at 11:00 PM, James Green < > james.mk.gr...@gmail.com> > > > wrote: > > > > Not sure this is even possible? > > > > > > > > We dynamically create our queues by pushing messages to channels with > > > > account numbers appended. They get read as the account reads from > it's > > > > queue. When that account goes dead and it's messages expired (or no > > more > > > get > > > > pushed) we then end up with many queues doing nothing but taking up > > space > > > on > > > > the web console. > > > > > > > > Is there perhaps a configuration directive to expire queues? I can't > > see > > > > anything in the STOMP protocol close to this. > > > > > > > > Thanks, > > > > > > > > James > > > > > > > > > >