Hi, as you are using queues, you don't have durable/non-durable subscriptions. But it appears to me that you do NOT close the last consumer, that's why the queue is not actually removed. You also should NEVER need to interact with the persistence adapter.
Still, the issue is that you should NOT NEED to remove the queue. I still think that you are not acknowledging the consumption of the message from the queue. Unfortunately I don't know anything about FlexClient or the like, I always only use plain JMS (without direct interaction with the ActiveMQ specifica) from within Java. Best regards, Martin On Wed, Nov 30, 2011 at 11:38 AM, Kevin Kilroy <kevkil...@gmail.com> wrote: > Hi, > > I'm using ActiveMQQueues, that are not persisted. The subscriptions > are non-durable. I'm removing the queues from the JMX bean by calling > removeQueue (which succeeds, as they dis-appear when viewed with > JConsole) - However, when I look with a profiler, I still see > ActiveMQQueue instances laying around. > > Therefore, I'm trying to remove these with: > > broker.getPersistenceAdapter().removeQueueMessageStore((ActiveMQQueue)dest); > broker.removeDestination(dest); > > But an exception is thrown on the removeDestination() call: > > "javax.jms.JMSException: Destination still has an active subscription: > queue://asfdasdf." > > As far as I'm aware, the FlexClient and it's subscriptions, have been > disconnected, by the session being timed-out. > > Is there a way to cancel the subscriptions on this destination > programmatically? As at this point in the app I am sure there are no > clients and I just want to clean up. > > Many thanks again for your input. > > Kevin. > > On Wed, Nov 30, 2011 at 10:14 AM, Martin C. <mart...@gmx.at> wrote: >> Hi, >> >> first thing: does it occur while there is a consumer? Or only if there >> is no consumer? Are you using queues or topics (maybe even with >> persistent subscriptions)? >> >> TTL basically works the way you expected, BUT it depends if the >> messages are persistent or not, and if you have configured expired >> messages to be stored in a dead-letter-queue. >> >> Best regards, >> Martin >> >> On Wed, Nov 30, 2011 at 8:53 AM, Kevin Kilroy <kevkil...@gmail.com> wrote: >>> Hi, >>> >>> Many thanks for your reply. There is a possibility in my app that >>> messages can't be delivered (client has closed the browser). I was >>> looking for a mechanism whereby there would be some sort of timeout on >>> the message, say a couple of minutes and if it hadn't been delivered >>> then the broker can delete it. I tried setting the timeToLive on the >>> Producer sending the message, but the build up of messages still >>> occurs. >>> >>> Any ideas? >>> >>> Thanks again, >>> >>> Kevin. >>> >>> On Wed, Nov 30, 2011 at 6:50 AM, Martin C. <mart...@gmx.at> wrote: >>>> Hi, >>>> >>>> if TotalMessageCount is not decreasing, this indicates that you are >>>> either not consuming or maybe not committing the consuming transaction >>>> / not acknowledging the messages on the receiving side (depends on >>>> your acknowledge mode). >>>> >>>> Best regards, >>>> Martin >>>> >>>> On Tue, Nov 29, 2011 at 4:39 PM, Kevin Kilroy <kevkil...@gmail.com> wrote: >>>>> Hi, >>>>> >>>>> I seem to have a memory leak, in that messages seem to be hanging >>>>> around in the broker. Using JMX I can see that the TotalMessageCount >>>>> is not 0. Also, MemoryPercentUsage eventually gets to 100% and then >>>>> the app freezes, if I increase the MemoryLimit, then the app begins to >>>>> run again. >>>>> >>>>> If I close down all the clients (browsers) then I see there are Consumers. >>>>> >>>>> I've tried setting a TimeToLive on the JmsTemplate (the Producer >>>>> sending the messages to the ActiveMQQueue). >>>>> >>>>> Does anybody have any ideas how I can debug this further? >>>>> >>>>> Thanks in advance, >>>>> >>>>> Kevin. >>>>> >>>>> I'm using Blazeds 4, Spring 3 and ActiveMQ 5.5. >>>>> >>> >
