Description
When using a FixedCountSubscriptionRecoveryPolicy on a topic I get millions of warnings when the topic is gc'd after inactivity. The impact is that warn logging has to be turned off which is not ideal. Looking in detail it seems this is caused by a couple of things. Firstly the Topic start method can be invoked twice, once when adding the destination to the RegionBroker and second when the regionBroker is started.
That causes the same expireMessagesTask to get scheduled twice which reveals the crux of the problem. The Scheduler allows the same task to be scheduled again in new TimerTasks, even though it will use the same key and ophan any existing (and running) TimerTasks. This is what's happening here. When the topic gets stopped, the orphaned tasks continue to run causing these spurious warnings that clog up the logs.
My suggestion would be for the scheduler to check if the task has already been registered using a putIfAbsent and fail if it already exists:
https://github.com/apache/activemq/blob/d9350912984f12356e9d51b0f00b5a28f5cfa58d/activemq-client/src/main/java/org/apache/activemq/thread/Scheduler.java#L42
These are the warnings we see:
2017-01-10 11:36:13,885 [host] Scheduler] - WARN Topic - Failed to browse Topic: myTopic
java.lang.NullPointerException
at org.apache.activemq.broker.region.policy.FixedCountSubscriptionRecoveryPolicy.browse(FixedCountSubscriptionRecoveryPolicy.java:103)
at org.apache.activemq.broker.region.policy.RetainedMessageSubscriptionRecoveryPolicy.browse(RetainedMessageSubscriptionRecoveryPolicy.java:111)
at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:677)
at org.apache.activemq.broker.region.Topic.access$1(Topic.java:639)
at org.apache.activemq.broker.region.Topic$2.run(Topic.java:791)
at org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505