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

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
time-to-live."

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 #82 in both Sections 3.4.9 and 4.8 of JMS 1.1.
#### Affected Versions
[1.1]

Read Section 4.8 of the JMS 1.1 specification and compare the proposed replacement text with the overlap noted in issue #82 and Section 3.4.9. The work is done when the permitted expiration-handling behavior and timing requirement have been agreed and the specification text is updated accordingly.

Written by the indexing model from the issue text.