search

jakartaee / messaging

Jakarta Messaging
https://eclipse.org/ee4j/messaging
Other
39 stars 33 forks source link

Section 8.7 of the JMS 2.0 spec has a malformed sentence #137

Open glassfishrobot opened 10 years ago

glassfishrobot commented 10 years ago

There is a confusing/malformed sentence in section 8.7 of the JMS 2.0 spec (also present in section 4.5.2 of 1.1 spec). The sentence is "Well behaved listeners should catch such exceptions and attempt to divert messages causing them to some form of application-specific 'unprocessable message' destination."

Is this trying to say ".. and attempt to divert messages to some form of application-specific ... ? In other words I feel like the words "causing them" should be removed from this sentence. In any case, it needs to be reworded somehow to make the meaning clear, in my opinion.

=== Larger quote:

8.7. Receiving messages asynchronously ...

It is possible for a listener to throw a RuntimeException; however, this is considered a client programming error. Well behaved listeners should catch such exceptions and attempt to divert messages causing them to some form of application-specific 'unprocessable message' destination.

Thanks! John Lindwall

Environment

N/A

Affected Versions

[1.1, 2.0]

glassfishrobot commented 6 years ago
glassfishrobot commented 10 years ago

@glassfishrobot Commented Reported by jlindwall

glassfishrobot commented 10 years ago

@glassfishrobot Commented @nigeldeakin said: The words "causing them" are used to suggest that the reason the listener might want to throw a RuntimeException is because there is something wrong (in application terms) with a message which prevents the message listener processing it, such as it containing invalid data.

That's why there is a suggestion that the listener should catch such exceptions and divert the "bad" message in question to to a dead message queue (DMQ) of some kind. The listener would continue to process the "good" messages as normal but would divert "bad" messages to the DMQ.

Note that the person developing the listener is free to ignore this advice and throw a RuntimeExceoption anyway. JMS provider will then behave as defined in this section.

glassfishrobot commented 7 years ago

@glassfishrobot Commented This issue was imported from java.net JIRA JMS_SPEC-137