That was by design, but this was improved on 2.2.2. You have a method to create a JMS queue persistently.
I would recommend anyone to move away from 2.1.2 due to the bug fixes on journal / compacting.
I'd like to add something else here.
I hadn't realised that I could just add the new queue to the hornetq.jms file and it would be added almost imediately to the queues at runtime.
I didn't know the file was monitored at runtime and this makes it much easier for me to manage changes.
I did notice that it doesn't seem to remove the queues if they are removed from there, but that's no big deal and obviously would prevent me from making a catestropic mistake by deleting the wrong queue if something happened.
>> "prevent me from making a catestropic mistake by deleting the wrong queue if something happened."
That's actually why we don't remove the core-queue case you remove the jms queue. We prefer having an active action on removing the queue than allowing accidental redeploy to drop data.
Version 2.2.5 this functionality no longer works.
In fact when I use createQueue("QueueName", "/queue/QueueName") on jmx, that queue is created fine, but when I restart, all the other queues in the jms file are missing.
They're still on the core queue, but what good is that if I'm using jms.
This behaviour was very useful as I could add queues without restarting and they were persistant across restarts.
What should I do now?
Will this behaviour be restored?