Issue Details (XML | Word | Printable)

Key: JMS_SPEC-83
Type: Improvement Improvement
Status: Open Open
Priority: Minor Minor
Assignee: Unassigned
Reporter: mickhayes
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
jms-spec

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

Created: 28/Feb/12 10:15 AM   Updated: 28/Mar/12 10:48 AM
Component/s: None
Affects Version/s: 1.1
Fix Version/s: None

Time Tracking:
Not Specified

Tags: pd20-forreview pd20-forreview-major
Participants: mickhayes and Nigel Deakin


 Description  « Hide

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 JMS_SPEC-82 in both Sections 3.4.9 and 4.8 of JMS 1.1.



Nigel Deakin made changes - 28/Feb/12 11:13 AM
Field Original Value New Value
Tags pd20-forreview
Nigel Deakin added a comment - 28/Feb/12 11:31 AM

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?

mickhayes added a comment - 28/Feb/12 12:04 PM

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.


Nigel Deakin added a comment - 28/Feb/12 12:30 PM

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?

Nigel


Nigel Deakin made changes - 28/Mar/12 10:48 AM
Tags pd20-forreview pd20-forreview pd20-forreview-major