This was raised by Hiram Chirino:
As an implementor of the JMS 1.1 spec one of the things that bother me about that version of the spec is the need to throw an exception when a client attempts to send a message to a temporary destination which has been deleted.
This isn't explicitly required in the JMS spec, but it appears to be required by the TCK tests. Hiram added:
If I recall correctly, I first encountered the requirement was when I was testing Geronimo against the JMS TCK. The TCK has a test case which checked the requirement I described. I guess the TCK implementors justify the test assertion due to the API documentation on send method that states throws 'InvalidDestinationException - if a client uses this method with a QueueSender with an invalid queue.'
Hiram gave the following as his justification:
You either have do an RPC against the server for each send to verify the temp destination is still around (which is slow since your working with non-persistent messages anyways) or the client has to monitor all temp destinations on the server which increases complexity of the client and the amount of memory it uses.
It also provides very little value to the end user application since NOT getting an exception does not guarantee the message will get processed. You could have a scenario where the producer sends a message to a temp destination and then the temp destination gets deleted which means the sent message gets dropped.
Hopefully the next version of the spec will be changed so that sending to a deleted temp destination does not throw a JMSException but instead the message gets dropped by the server.