You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Mathias Stalas (JIRA)" <ji...@apache.org> on 2009/05/28 12:35:51 UTC

[jira] Created: (SMX4-289) Amq queues still hangs around even after a manually delete of an SA containing a jms provider SU that resigns in the hotdeploy directory

Amq queues still hangs around even after a manually delete of an SA containing a jms provider SU that resigns in the hotdeploy directory
----------------------------------------------------------------------------------------------------------------------------------------

                 Key: SMX4-289
                 URL: https://issues.apache.org/activemq/browse/SMX4-289
             Project: ServiceMix 4
          Issue Type: Bug
         Environment: OS Ubuntu/Linux, JDK build 1.6.0_10-b33, Servicemix version 3.3
            Reporter: Mathias Stalas
            Assignee: Jean-Baptiste Onofré


When deleting(manually) an SA artifact that contains an JMS SU that holds one or more jms endpoints from the hotdeploy directory the queues that is created at the broker by the JMS SU are not removed from the broker. Bringing down and restarting servicemix dosent help either. The queues still remains.

Work around:
Use jmx and jconsole to manually delete the queues.

It would be nice if the created queues would go away or even nicer if this feature was configurable from within the xbean.xml conf for diffrent requirements.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (SMX4-289) Amq queues still hangs around even after a manually delete of an SA containing a jms provider SU that resigns in the hotdeploy directory

Posted by "Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/activemq/browse/SMX4-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Baptiste Onofré resolved SMX4-289.
---------------------------------------

    Resolution: Won't Fix

According to Gert, this actually is an ActiveMQ feature at work.  Many message broker
require you to set up queues before you can use them, but ActiveMQ
creates a queue/topic on the fly as you send your first message to it.
 Whenever we create a temporary queue (e.g. for handing an InOut MEP),
we do delete that afterwards, but not for 'real' JMS queues -- once
defined in the broker, they remain there until someone removes them.

Currently, there's no option available to delete all empty queues
on startup or something (we don't want to delete queues that have
messages in there, I guess) and that's mostly because there's hardly
any overhead in having an empty queue in the broker.  So this
basically is a feature rather than a bug (I bet you've heard that one
before  ;)  ), but if you would like to see this extra option being
added, I'll gladly move the SMX4 issue and make it an ActiveMQ issue
for you.

> Amq queues still hangs around even after a manually delete of an SA containing a jms provider SU that resigns in the hotdeploy directory
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SMX4-289
>                 URL: https://issues.apache.org/activemq/browse/SMX4-289
>             Project: ServiceMix 4
>          Issue Type: Bug
>         Environment: OS Ubuntu/Linux, JDK build 1.6.0_10-b33, Servicemix version 3.3
>            Reporter: Mathias Stalas
>            Assignee: Jean-Baptiste Onofré
>
> When deleting(manually) an SA artifact that contains an JMS SU that holds one or more jms endpoints from the hotdeploy directory the queues that is created at the broker by the JMS SU are not removed from the broker. Bringing down and restarting servicemix dosent help either. The queues still remains.
> Work around:
> Use jmx and jconsole to manually delete the queues.
> It would be nice if the created queues would go away or even nicer if this feature was configurable from within the xbean.xml conf for diffrent requirements.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.