1. jms-spec
  2. JMS_SPEC-83

Tighter specification of Expired Message Handling in Section 4.8 "Message Time-to-Live"


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


      A great saving of system resources, in some cases, can be made by expeditious destruction of each undelivered message that satisfies the expiration criterion set on it.

      1.1 of the standard is deliberately best-effortish in the area of Expired Message Handling, and it is well-understood that this was appropriate at the time. The result, however, was that users ended up with no certainty about when a message would expire, if ever. The handling was quirky, and varied between JMS Provider implementations.

      Tightening up the handling in this area should not now lead to the exclusion of any JMS Provider implementation due to inability to comply, so it appears that the time is right to proceed with this improvement.

      Tighter specification in this manner is naturally backward-compatible in that the new tighter behaviour would automatically be as-good-as-or-better than experienced with JMS 1.1-compliant Providers. One must remain mindful, of course, that there is a processing cost per expiration check that must be paid.

      It remains, then, to agree to what extent such a tightening is useful.

      I propose that 4.8 is updated by replacing the sentences:

      "A JMS provider should do its best to expire messages accurately; however, JMS
      does not define the accuracy provided. It is not acceptable to simply ignore

      with new text:

      "A JMS provider should do its best to expire messages accurately. No undelivered message should remain unhandled for this purpose for more than 30 seconds."

      For messages with distant expiration, this wording does not preclude a Provider implementation marking such messages, and thereafter checking messages so-marked less frequently than the 30 seconds (or whatsoever figure can be agreed) in 4.8.

      I do not propose any change for Section 3.4.9, but I should mention an overlap with JMS_SPEC-82 in both Sections 3.4.9 and 4.8 of JMS 1.1.



          • Assignee:
          • Votes:
            0 Vote for this issue
            0 Start watching this issue


            • Created: