]
Jeff Mesnil updated WFLY-1513:
------------------------------
Fix Version/s: 9.0.0.Alpha1
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.