remove operation on JMS queue/topic doesn't remove the destination but just unbinds from JNDI --------------------------------------------------------------------------------------------- Key: WFLY-1513 URL: https://issues.jboss.org/browse/WFLY-1513 Project: WildFly Issue Type: Bug Security Level: Public(Everyone can see) Components: Domain Management, JMS Affects Versions: 8.0.0.Alpha1, 8.0.0.Alpha2 Reporter: jaikiran pai Assignee: Jeff Mesnil Fix For: 9.0.0.Alpha1 The remove (management) operation on a JMS queue merely unbinds the queue from JNDI instead of destroying the queue. It appears that the change was done as part of https://issues.jboss.org/browse/AS7-1899 (the PR is here https://github.com/wildfly/wildfly/pull/398). The change done in that PR to address the original issue reported in that other JIRA doesn't look right. So the original issue reported in that thread is that a server has a queue with messages and the server is stopped. Upon restart the messages have disappeared because upon stop, the JMSQueueService's stop() method used to destroy the queue. The real fix would have been to differentiate the "remove()" operation from a mere service stop. The explicit remove (handler) would then be responsible for destroying the queue (which even means a JNDI unbind) and not that service's stop method. All of this even applies to the JMS topic which has a similar problem. On a related note, the add() operation too seems suspicious because it ends up calling a createXXX on the JMSServer API which says: {code} /** * Creates a JMS Queue. * * @param queueName * The name of the queue to create * @param selectorString * @param durable * @return true if the queue is created or if it existed and was added to * JNDI * @throws Exception * if problems were encountered creating the queue. */ boolean createQueue(boolean storeConfig, String queueName, String selectorString, boolean durable, String ...bindings) throws Exception; {code} Notice the "if the queue is created or if it existed and was added to JNDI" part. So it appears that the management "add" operation can end up behaving like an update (write-attribute) kind of operation in some cases. I'm not sure if that's good thing.