the destination garbage collection only kicks in if there are no consumers and no messages. so the producer is keeping this temp destination alive... one option is to purge the queue, so that the message count goes to 0. But I think we need to understand why the temp queue is created and not deleted in this case. A test case would be great, so that we could validate against the current trunk and figure out if we need to have the option to delete temp destinations that have pending messages or implement better control temp destination lifecycle across networks.
On 28 March 2012 17:27, Marcin Giedz <marcin.gi...@arise.pl> wrote: > Hi, > > Once again full config: > > <broker xmlns="http://activemq.apache.org/schema/core"; > brokerName="waw1-amq1" dataDirectory="${activemq.base}/data" useJmx="true" > advisorySupport="true" peschedulePeriodForDestinationPurge="10000" > allowTempAutoCreationOnSend="true"> > > <!-- > Use VM cursor > For more information, see: > http://activemq.apache.org/message-cursors.html > --> > <destinationPolicy> > <policyMap> > <policyEntries> > <policyEntry topic=">" producerFlowControl="true" > memoryLimit="100mb"> > <pendingSubscriberPolicy> > <fileCursor/> > </pendingSubscriberPolicy> > </policyEntry> > <policyEntry queue=">" producerFlowControl="true" > memoryLimit="100mb"> > <pendingQueuePolicy> > <vmQueueCursor/> > </pendingQueuePolicy> > </policyEntry> > > <policyEntry tempTopic="true" producerFlowControl="true" > memoryLimit="100mb"> > <pendingSubscriberPolicy> > <fileCursor/> > </pendingSubscriberPolicy> > </policyEntry> > <policyEntry tempQueue="true" producerFlowControl="true" > memoryLimit="100mb" gcInactiveDestinations="true" inactiveTimoutBeforeG > <pendingQueuePolicy> > <vmQueueCursor/> > </pendingQueuePolicy> > </policyEntry> > > </policyEntries> > </policyMap> > </destinationPolicy> > > > <managementContext> > <managementContext createConnector="true"/> > </managementContext> > > <networkConnectors> > <networkConnector uri="static:(tcp://172.16.36.7:61616)"> > <dynamicallyIncludedDestinations/> > <excludedDestinations> > <queue physicalName="pl.arise.cms.to.pats"/> > <queue physicalName="pl.arise.cmsproxy"/> > <queue physicalName="pl.arise.dictionaryservice"/> > <queue physicalName="pl.arise.omsauthorization"/> > <queue physicalName="pl.arise.omsinstruments"/> > <queue physicalName="pl.arise.omsorderbook"/> > <queue physicalName="pl.arise.omsserver"/> > <queue physicalName="pl.arise.omsfixserver"/> > <queue physicalName="pl.arise.omstradeserver"/> > <queue physicalName="pl.arise.permissionsservice"/> > <queue physicalName="pl.arise.settingsservice"/> > <queue physicalName="pl.arise.sirorderbookserver"/> > <topic physicalName="BSE"/> > <topic physicalName="SIR"/> > <topic physicalName="pl.arise.statusserver"/> > </excludedDestinations> > </networkConnector> > </networkConnectors> > > <!-- > Use KahaDB for persistence > Tune it a bit so we minimize IO operations > For more information, see: > http://activemq.apache.org/kahadb.html > --> > <persistenceAdapter> > <kahaDB directory="${activemq.base}/data/kahadb" > enableJournalDiskSyncs="false" indexWriteBatchSize="10000" > indexCacheSize="1000"/> > </persistenceAdapter> > > > <systemUsage> > <systemUsage> > <memoryUsage> > <memoryUsage limit="24 gb"/> > </memoryUsage> > <storeUsage> > <storeUsage limit="10 gb" name="store"/> > </storeUsage> > <tempUsage> > <tempUsage limit="10 gb"/> > </tempUsage> > </systemUsage> > </systemUsage> > > > <!-- > Use TCP transport > For more information, see: > http://activemq.apache.org/configuring-transports.html > --> > <transportConnectors> > <transportConnector name="openwire" > uri="nio://0.0.0.0:61616?keepAlive=true"/> > </transportConnectors> > > </broker> > > Results: > > some temp-queues are removed some not. I don;t know if maillist can accept > attachment but I'm sending jconsole example for temp-queues which are not > removed ... these temp queues have ConsumerCOunt=0 and EnqueueCount value is > increasing so more and more memory is taken. Such dead-active temp-queues > stay when application which creates it hangs or a network problem is > simulated. In such cases they are not removed by the system but should be > removed by AMQ after inactivity time reaches its level, right? > > I guess AMQ still things that this particular temp-queue is active as > producer creates knew messages on it. In such case is there any way to push > AMQ to remove such temp-queue? > > Thx > M. > > > ________________________________ > Od: "Marcin Giedz" <marcin.gi...@arise.pl> > Do: users@activemq.apache.org > Wysłane: poniedziałek, 26 marzec 2012 14:56:58 > > Temat: Re: AMQ 5.5 remove temporary destination > > Thx a lot... I will check this and send you a results ;) > > > Thx > Marcin > > ----- Oryginalna wiadomość ----- > > Od: "Dejan Bosanac" <de...@nighttale.net> > Do: users@activemq.apache.org > Wysłane: poniedziałek, 26 marzec 2012 14:54:02 > Temat: Re: AMQ 5.5 remove temporary destination > > Yes, it should be there since 5.4.0. It checks if destination is empty and > doesn't have any producers/consumers for a certain time. > > > Regards > -- > Dejan Bosanac > Senior Software Engineer | FuseSource Corp. > dej...@fusesource.com | fusesource.com > skype: dejan.bosanac | twitter: @dejanb > blog: http://www.nighttale.net > ActiveMQ in Action: http://www.manning.com/snyder/ > > > > On Mon, Mar 26, 2012 at 12:55 PM, Marcin Giedz <marcin.gi...@arise.pl>wrote: > >> Hi Dejan, >> >> >> Thx for you update... I assume 5.5.1-fuse contains this fix? >> >> >> and: how AMQ decides which temp-queue is about to be removed - what >> condition pls? >> >> >> Thx >> Marcin >> >> ----- Oryginalna wiadomość ----- >> >> Od: "Dejan Bosanac" <de...@nighttale.net> >> Do: users@activemq.apache.org >> Wysłane: poniedziałek, 26 marzec 2012 11:31:37 >> Temat: Re: AMQ 5.5 remove temporary destination >> >> Try adding <broker .... allowTempAutoCreationOnSend="true"> >> >> so that gc include temporary destinations as well. >> >> >> Regards >> -- >> Dejan Bosanac >> Senior Software Engineer | FuseSource Corp. >> dej...@fusesource.com | fusesource.com >> skype: dejan.bosanac | twitter: @dejanb >> blog: http://www.nighttale.net >> ActiveMQ in Action: http://www.manning.com/snyder/ >> >> >> >> On Fri, Mar 23, 2012 at 3:13 PM, Marcin Giedz <marcin.gi...@arise.pl> >> wrote: >> >> > >> > Hi, >> > >> > >> > Our temp queue policy is set as follows: >> > >> > >> > <policyEntry tempQueue="true" producerFlowControl="true" >> > memoryLimit="100mb" gcInactiveDestinations="true" >> > inactiveTimoutBeforeGC="30000"> >> > <pendingQueuePolicy> >> > <vmQueueCursor/> >> > </pendingQueuePolicy> >> > </policyEntry> >> > >> > >> > question: what conditions are taken into account in case of "remove daed >> > temp queues"? - number of consumers, producers, etc? >> > >> > >> > With such configuration I still can see live temp-queues with >> > ConsumerCount=0 - I thought that this could trigger AMQ to remove such >> > queue but it doesn't. Did I miss something in configuration? >> > >> > >> > Thx >> > Marcin >> >> >> >> >> > > > > -- > > > Pozdrawiam > Marcin Giedz > Wiceprezes Zarządu > > ARISE Sp. z o.o. > mob. +48 502 537 157 > mail: marcin.gi...@arise.pl > > ul. Waliców 11 > 00-851 Warszawa > tel./fax +48 (22) 583 93 40 > http: www.arise.pl > > ARISE Sp. z o.o. z siedzibą w Warszawie, ul. Al. Solidarności 117, 00-140 > Warszawa, zarejestrowana przez Sąd Rejonowy dla m. st. Warszawy w Warszawie > XII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 0000316860; > REGON 141595449; NIP 527-259-06-10; z pokrytym w całości kapitałem > zakładowym wynoszącym 50,000.00 zł. > > > > > > -- > > Pozdrawiam > Marcin Giedz > Wiceprezes Zarządu > > ARISE Sp. z o.o. > mob. +48 502 537 157 > mail: marcin.gi...@arise.pl > > ul. Waliców 11 > 00-851 Warszawa > tel./fax +48 (22) 583 93 40 > http: www.arise.pl > > ARISE Sp. z o.o. z siedzibą w Warszawie, ul. Al. Solidarności 117, 00-140 > Warszawa, zarejestrowana przez Sąd Rejonowy dla m. st. Warszawy w Warszawie > XII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 0000316860; > REGON 141595449; NIP 527-259-06-10; z pokrytym w całości kapitałem > zakładowym wynoszącym 50,000.00 zł. > > -- http://fusesource.com http://blog.garytully.com
