[
https://issues.apache.org/jira/browse/AMQ-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875800#comment-13875800
]
Arthur Naseef commented on AMQ-4970:
------------------------------------
Here's the finding:
* The issue is caused, at least in part, by redundant starts of the Queue (i.e.
two calls to Queue.start)
* On the head, this still happens
* On the older code, the redundant start causes redundant exipred-message
scheduling which appears to cause the Queue to revive after a removeDestination
** The revival only takes affect on broker restart
** So, the kahadb remembers the destination, but it doesn't revive in broker
memory
* On the head, the redundant start doesn't lead to the revival; not sure why.
I recommend protecting against redundant starts by adding a flag and check to
the Queue - using encapsulation to have the Queue keep itself robust. Even
without the queue revival, redundant starts of the Queue can only lead to
problems (such as a scheduler task leak). I'll submit a patch.
> Deletion of a queue inaffective across broker restart
> -----------------------------------------------------
>
> Key: AMQ-4970
> URL: https://issues.apache.org/jira/browse/AMQ-4970
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.9.0
> Environment: mac osx/mavericks
> Reporter: Arthur Naseef
> Attachments: AMQ4970Test.zip, AMQ4970Test.zip, AMQ4970Test.zip
>
>
> Deleting a queue, it is revived from persistent store after a broker restart.
> The following steps reproduce the problem:
> * Create a queue (confirmed using the REST client I/F)
> * Shutdown the broker
> * Startup the broker
> * Confirm queue still exists via the hawtio ui (correct operation so far)
> * Delete the queue
> * Confirm queue removed via the hawtio ui
> * Shutdown the broker
> * Startup the broker
> * Confirm queue was not recreated via hawtio ui (failed: queue still exists)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
