messaging
messaging copied to clipboard
jakartaee
Relaxing the requirement to throw an exception if a message is sent to a deleted temp destination
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.
Affected Versions
[1.1]
- Issue Imported From: https://github.com/javaee/jms-spec/issues/67
- Original Issue Raised By:@glassfishrobot
- Original Issue Assigned To: Unassigned
@glassfishrobot Commented @nigeldeakin said: This will be reviewed by the expert group for possible inclusion in the JMS 2.0 public draft. Tagging accordingly.
@glassfishrobot Commented This issue was imported from java.net JIRA JMS_SPEC-67