jms-spec
  1. jms-spec
  2. JMS_SPEC-83

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

    Details

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

      Description

      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.

        Activity

        Hide
        Nigel Deakin added a comment -

        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

        Show
        Nigel Deakin added a comment - 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
        Hide
        mickhayes added a comment -

        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.

        Show
        mickhayes added a comment - 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.
        Hide
        Nigel Deakin added a comment -

        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?
        Show
        Nigel Deakin added a comment - 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?

          People

          • Assignee:
            Unassigned
            Reporter:
            mickhayes
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: