Clebert Suconic wrote:
I was talking to kconner and tfenelly today on IRC regarding this issue: http://community.jboss.org/message/552210#552210
and I was thinking: Wouldn't be okay to change the AS deployers to destroy the queues if there are no messages on the queue?
Tom and Kevin liked the idea. I wanted to know if anyone would see an issue on doing it.
I dont think we should change this, undeploy should not mean delete, I think we have discussed this a few times and actually changed the API tp be correct. However if you want to changethe AS deployers to call delete/destroy on the HQ API then that is a different matter.
We probably discussed this a million times already.
Undeploying using JMSServerDeployer means "remove from JNDI/JMX" it does not mean delete queue.
if you want to delete the queue there are other management operations that do that.
I know this was discussed before.
This question was raised when I was talking to Tom and Kevin yesterday.
IMO it would make more sense for the Application Server users to delete the destinations when they are empty.
what would be a reason to not do it besides we talked about it before?
The only reason I could think is not losing data case there are messages on the queue. But I'm talking here about the case when the queue is being undeployed and there are no messages on it.
Ok, there is a bit of confusion here, i have talked to Kevin and here is what is happening and what should happen.
when the AS deployed deploy a queue we call createqueue on the jms server api, this does the following:
1. creates the queue
2. creates and registers a jms queue control object (mbean) with the mbean server
3. register it with jndi
currently when we undeploy the queue all we do is remove it from jndi. What we also need to do is remove step 2 unregister the jms queue object as well. Note we *dont* want to delete the underlying queue.
yes.. there's a bug .. the removeFromJNDI should also remove the JMX instance for it and I have created a JIRA.
and we talked about the core queues beyond of that scope also (I, Kevin and Tom)
As for the core queues, I haven't seen a reason for keeping them besides we *don't want to do it*.... anyway... I will live with it. I just started the discussion again as we had the talk.