[JMS_SPEC-83] Tighter specification of Expired Message Handling in Section 4.8 "Message Time-to-Live" Created: 28/Feb/12  Updated: 28/Mar/12

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: 1.1
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: mickhayes Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: pd20-forreview, pd20-forreview-major


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.

Comment by Nigel Deakin [ 28/Feb/12 ]

Tagged for review by the expert group for the public draft.

If this were changed (and this needs to be discussed with the EG) then I think section 3.4.9 "JMSExpiration" and section 4.8 "Message time-to-live" should both be updated.

I think the proposed wording "No undelivered message should remain unhandled for this purpose for more than 30 seconds" is not very clear, and it would be better to express it from a client point of view - something like "Clients must not receive messages more than 30 seconds after their expiry time". If we tighten this up we would also need to be more specific about how expiry is applied in cases such as transactions and rollback. For example:

  • A message is received in a transaction. The transaction is rolled back. The message then reaches its expiry time. Should the message be redelivered?
Comment by mickhayes [ 28/Feb/12 ]

I agree the wording is poor, especially the double negative. However, the intention goes beyond the suggested client-centric wording above.
The aim here is to free up broker resources, rather than to ensure that the clients don't receive too-old messages.

The closer to its specified expiration that a message is destroyed, the greater the saving in broker resources, all other things being equal.

Client resources are likewise conserved. A result of more expeditious destruction may be a smaller (but not-necessarily-zero) number of too-old messages that a client has to handle.

Comment by Nigel Deakin [ 28/Feb/12 ]

JMS doesn't define whether messages are expired on the server or on the receiving client (or both). So long as the required external behaviour is exhibited I think it's up to the JMS vendor to decide how to implement it. How would the client, or a compliance test, be able to tell the difference?

If your aim is to allow the server to manage its resources better, is there anything in the JMS API that prevents implementations doing this now?


Generated at Thu Jun 30 01:51:13 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.