search

jakartaee / messaging

Jakarta Messaging
https://eclipse.org/ee4j/messaging
Other
39 stars 32 forks source link

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

Open glassfishrobot opened 12 years ago

glassfishrobot commented 12 years ago

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]

glassfishrobot commented 6 years ago
glassfishrobot commented 12 years ago

@glassfishrobot Commented Reported by mickhayes

glassfishrobot commented 12 years ago

@glassfishrobot Commented @nigeldeakin said: 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:

glassfishrobot commented 12 years ago

@glassfishrobot Commented mickhayes said: 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.

glassfishrobot commented 12 years ago

@glassfishrobot Commented @nigeldeakin said: 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

glassfishrobot commented 7 years ago

@glassfishrobot Commented This issue was imported from java.net JIRA JMS_SPEC-83