You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Christopher L. Shannon (JIRA)" <ji...@apache.org> on 2017/01/10 13:32:58 UTC

[jira] [Commented] (AMQ-6555) Failed to browse topic warnings caused by orphaned expire message tasks in Sceduler

    [ https://issues.apache.org/jira/browse/AMQ-6555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15814978#comment-15814978 ] 

Christopher L. Shannon commented on AMQ-6555:
---------------------------------------------

I think the main fix here is to prevent the start method from being called a second time and a check can also be added to the Scheduler as a precaution as well.  However instead of a put if absent it might be better to cancel the old task and then start/add the new one in case the period has changed.  We can log a warning as well.  I can't really think of any current use cases where this would/should happen but figure it's worth putting the check in there as a precaution.

> Failed to browse topic warnings caused by orphaned expire message tasks in Sceduler
> -----------------------------------------------------------------------------------
>
>                 Key: AMQ-6555
>                 URL: https://issues.apache.org/jira/browse/AMQ-6555
>             Project: ActiveMQ
>          Issue Type: Bug
>    Affects Versions: 5.14.1
>            Reporter: jack
>            Assignee: Christopher L. Shannon
>
> 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



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)