You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2019/08/27 14:39:00 UTC

[jira] [Work logged] (ARTEMIS-2462) Allow store and forward queue to be deleted after scaledown

     [ https://issues.apache.org/jira/browse/ARTEMIS-2462?focusedWorklogId=302036&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-302036 ]

ASF GitHub Bot logged work on ARTEMIS-2462:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 27/Aug/19 14:38
            Start Date: 27/Aug/19 14:38
    Worklog Time Spent: 10m 
      Work Description: gaohoward commented on pull request #2813: ARTEMIS-2462 Allow store-forward queue to be deleted afte scaledown
URL: https://github.com/apache/activemq-artemis/pull/2813
 
 
   After a node is scaled down to a target node, the sf queue in the
   target node is not deleted.
   
   Normally this is fine because may be reused when the scaled down
   node is back up.
   
   However in cloud environment many drainer pods can be created and
   then shutdown in order to drain the messages to a live node (pod).
   Each drainer pod will have a different node-id. Over time the sf
   queues in the target broker node grows and those sf queues are
   no longer reused.
   
   Although use can use management API/console to manually delete
   them, it would be nice to have an option to automatically delete
   those sf queue/address resources after scale down.
   
   In this PR it defines a system property on the scale down broker.
   If the property is "true" the broker will send a message to the
   target broker signalling that the SF queue is no longer
   needed and should be deleted.
   If the property is not defined (default) or other values
   than "true", the scale down won't remove the sf queue.
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Issue Time Tracking
-------------------

            Worklog Id:     (was: 302036)
    Remaining Estimate: 0h
            Time Spent: 10m

> Allow store and forward queue to be deleted after scaledown
> -----------------------------------------------------------
>
>                 Key: ARTEMIS-2462
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-2462
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 2.10.0
>            Reporter: Howard Gao
>            Priority: Minor
>             Fix For: 2.11.0
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> After a node is scaled down to a target node, the sf queue in the target node is not deleted (the sf queue takes the form of $.artemis.internal.sf.<cluster-name>.<nodeid>).
> Normally this is fine because maybe reused when the scaled down node is back up.
> However in Openshift/Kubernetes environment many drainer pod (scale down broker) can be created and then shutdown in order to drain the messages to a live node (pod). Each drainer pod will have a different node-id. Over time the sf queues in the target broker node grows and those sf queues are no longer reused.
> Although use can use management API/console to manually delete them, it would be nice to have an option to automatically delete those sf queue/address resources after scale down.
> One option (my proposal) is define a system property on the scale down broker.
> If the property is "true" the broker will send a message to the target broker signalling that the SF queue is no longer needed and should be deleted.
> If the property is not defined (default) or other values then "true", the scale down won't remove the sf queue (current behavior).
> This solution could well be suitable for openshift/kubernetes environment because we can easily pass any environment variable into the image to enable/disable this feature.
>  



--
This message was sent by Atlassian Jira
(v8.3.2#803003)