jms-spec
  1. jms-spec
  2. JMS_SPEC-137

Section 8.7 of the JMS 2.0 spec has a malformed sentence

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.1, 2.0
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      N/A

      Description

      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

        Activity

        Hide
        Nigel Deakin added a comment -

        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.

        Show
        Nigel Deakin added a comment - 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.

          People

          • Assignee:
            Unassigned
            Reporter:
            jlindwall
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: