jms-spec
  1. jms-spec
  2. JMS_SPEC-67

Relaxing the requirement to throw an exception if a message is sent to a deleted temp destination

    Details

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

      Description

      This was raised by Hiram Chirino:

      As an implementor of the JMS 1.1 spec one of the things that bother me about that version of the spec is the need to throw an exception when a client attempts to send a message to a temporary destination which has been deleted.

      This isn't explicitly required in the JMS spec, but it appears to be required by the TCK tests. Hiram added:

      If I recall correctly, I first encountered the requirement was when I was testing Geronimo against the JMS TCK. The TCK has a test case which checked the requirement I described. I guess the TCK implementors justify the test assertion due to the API documentation on send method that states throws 'InvalidDestinationException - if a client uses this method with a QueueSender with an invalid queue.'

      Hiram gave the following as his justification:

      You either have do an RPC against the server for each send to verify the temp destination is still around (which is slow since your working with non-persistent messages anyways) or the client has to monitor all temp destinations on the server which increases complexity of the client and the amount of memory it uses.

      It also provides very little value to the end user application since NOT getting an exception does not guarantee the message will get processed. You could have a scenario where the producer sends a message to a temp destination and then the temp destination gets deleted which means the sent message gets dropped.

      Hopefully the next version of the spec will be changed so that sending to a deleted temp destination does not throw a JMSException but instead the message gets dropped by the server.

        Activity

        Nigel Deakin created issue -
        Nigel Deakin made changes -
        Field Original Value New Value
        Description This was raised by Hiram Chirino:

        {quote}
        As an implementor of the JMS 1.1 spec one of the things that bother me about that version of the spec is the need to throw an exception when a client attempts to send a message to a temporary destination which has been deleted.
        {quote}

        This isn't explicitly required in the JMS spec, but it appears to be required by the TCK tests. Hiram added:

        {quote}
        If I recall correctly, I first encountered the requirement was when I was testing Geronimo against the JMS TCK. The TCK has a test case which checked the requirement I described. I guess the TCK implementors justify the test assertion due to the API documentation on send method that states throws 'InvalidDestinationException - if a client uses this method with a QueueSender with an invalid queue.'
        {quote}
        This was raised by Hiram Chirino:

        {quote}
        As an implementor of the JMS 1.1 spec one of the things that bother me about that version of the spec is the need to throw an exception when a client attempts to send a message to a temporary destination which has been deleted.
        {quote}

        This isn't explicitly required in the JMS spec, but it appears to be required by the TCK tests. Hiram added:

        {quote}
        If I recall correctly, I first encountered the requirement was when I was testing Geronimo against the JMS TCK. The TCK has a test case which checked the requirement I described. I guess the TCK implementors justify the test assertion due to the API documentation on send method that states throws 'InvalidDestinationException - if a client uses this method with a QueueSender with an invalid queue.'
        {quote}

        Hiram gave the following as his justification:

        {quote}
        As an implementor of the JMS 1.1 spec one of the things that bother me about that version of the spec is the need to throw an exception when a client attempts to send a message to a temporary destination which
        has been deleted.

        You either have do an RPC against the server for each send to verify the temp destination is still around (which is slow since your working with non-persistent messages anyways) or the client has to monitor all
        temp destinations on the server which increases complexity of the client and the amount of memory it uses.

        It also provides very little value to the end user application since NOT getting an exception does not guarantee the message will get processed. You could have a scenario where the producer sends a
        message to a temp destination and then the temp destination gets deleted which means the sent message gets dropped.

        Hopefully the next version of the spec will be changed so that sending to a deleted temp destination does not throw a JMSException but instead the message gets dropped by the server.
        {quote}
        Tags pd20-forreview
        Nigel Deakin made changes -
        Description This was raised by Hiram Chirino:

        {quote}
        As an implementor of the JMS 1.1 spec one of the things that bother me about that version of the spec is the need to throw an exception when a client attempts to send a message to a temporary destination which has been deleted.
        {quote}

        This isn't explicitly required in the JMS spec, but it appears to be required by the TCK tests. Hiram added:

        {quote}
        If I recall correctly, I first encountered the requirement was when I was testing Geronimo against the JMS TCK. The TCK has a test case which checked the requirement I described. I guess the TCK implementors justify the test assertion due to the API documentation on send method that states throws 'InvalidDestinationException - if a client uses this method with a QueueSender with an invalid queue.'
        {quote}

        Hiram gave the following as his justification:

        {quote}
        As an implementor of the JMS 1.1 spec one of the things that bother me about that version of the spec is the need to throw an exception when a client attempts to send a message to a temporary destination which
        has been deleted.

        You either have do an RPC against the server for each send to verify the temp destination is still around (which is slow since your working with non-persistent messages anyways) or the client has to monitor all
        temp destinations on the server which increases complexity of the client and the amount of memory it uses.

        It also provides very little value to the end user application since NOT getting an exception does not guarantee the message will get processed. You could have a scenario where the producer sends a
        message to a temp destination and then the temp destination gets deleted which means the sent message gets dropped.

        Hopefully the next version of the spec will be changed so that sending to a deleted temp destination does not throw a JMSException but instead the message gets dropped by the server.
        {quote}
        This was raised by Hiram Chirino:

        {quote}
        As an implementor of the JMS 1.1 spec one of the things that bother me about that version of the spec is the need to throw an exception when a client attempts to send a message to a temporary destination which has been deleted.
        {quote}

        This isn't explicitly required in the JMS spec, but it appears to be required by the TCK tests. Hiram added:

        {quote}
        If I recall correctly, I first encountered the requirement was when I was testing Geronimo against the JMS TCK. The TCK has a test case which checked the requirement I described. I guess the TCK implementors justify the test assertion due to the API documentation on send method that states throws 'InvalidDestinationException - if a client uses this method with a QueueSender with an invalid queue.'
        {quote}

        Hiram gave the following as his justification:

        {quote}
        As an implementor of the JMS 1.1 spec one of the things that bother me about that version of the spec is the need to throw an exception when a client attempts to send a message to a temporary destination which has been deleted.

        You either have do an RPC against the server for each send to verify the temp destination is still around (which is slow since your working with non-persistent messages anyways) or the client has to monitor all temp destinations on the server which increases complexity of the client and the amount of memory it uses.

        It also provides very little value to the end user application since NOT getting an exception does not guarantee the message will get processed. You could have a scenario where the producer sends a message to a temp destination and then the temp destination gets deleted which means the sent message gets dropped.

        Hopefully the next version of the spec will be changed so that sending to a deleted temp destination does not throw a JMSException but instead the message gets dropped by the server.
        {quote}
        Nigel Deakin made changes -
        Description This was raised by Hiram Chirino:

        {quote}
        As an implementor of the JMS 1.1 spec one of the things that bother me about that version of the spec is the need to throw an exception when a client attempts to send a message to a temporary destination which has been deleted.
        {quote}

        This isn't explicitly required in the JMS spec, but it appears to be required by the TCK tests. Hiram added:

        {quote}
        If I recall correctly, I first encountered the requirement was when I was testing Geronimo against the JMS TCK. The TCK has a test case which checked the requirement I described. I guess the TCK implementors justify the test assertion due to the API documentation on send method that states throws 'InvalidDestinationException - if a client uses this method with a QueueSender with an invalid queue.'
        {quote}

        Hiram gave the following as his justification:

        {quote}
        As an implementor of the JMS 1.1 spec one of the things that bother me about that version of the spec is the need to throw an exception when a client attempts to send a message to a temporary destination which has been deleted.

        You either have do an RPC against the server for each send to verify the temp destination is still around (which is slow since your working with non-persistent messages anyways) or the client has to monitor all temp destinations on the server which increases complexity of the client and the amount of memory it uses.

        It also provides very little value to the end user application since NOT getting an exception does not guarantee the message will get processed. You could have a scenario where the producer sends a message to a temp destination and then the temp destination gets deleted which means the sent message gets dropped.

        Hopefully the next version of the spec will be changed so that sending to a deleted temp destination does not throw a JMSException but instead the message gets dropped by the server.
        {quote}
        This was raised by Hiram Chirino:

        {quote}
        As an implementor of the JMS 1.1 spec one of the things that bother me about that version of the spec is the need to throw an exception when a client attempts to send a message to a temporary destination which has been deleted.
        {quote}

        This isn't explicitly required in the JMS spec, but it appears to be required by the TCK tests. Hiram added:

        {quote}
        If I recall correctly, I first encountered the requirement was when I was testing Geronimo against the JMS TCK. The TCK has a test case which checked the requirement I described. I guess the TCK implementors justify the test assertion due to the API documentation on send method that states throws 'InvalidDestinationException - if a client uses this method with a QueueSender with an invalid queue.'
        {quote}

        Hiram gave the following as his justification:

        {quote}
        You either have do an RPC against the server for each send to verify the temp destination is still around (which is slow since your working with non-persistent messages anyways) or the client has to monitor all temp destinations on the server which increases complexity of the client and the amount of memory it uses.

        It also provides very little value to the end user application since NOT getting an exception does not guarantee the message will get processed. You could have a scenario where the producer sends a message to a temp destination and then the temp destination gets deleted which means the sent message gets dropped.

        Hopefully the next version of the spec will be changed so that sending to a deleted temp destination does not throw a JMSException but instead the message gets dropped by the server.
        {quote}
        Nigel Deakin made changes -
        Tags pd20-forreview pd20-forreview pd20-forreview-minor
        Nigel Deakin made changes -
        Tags pd20-forreview pd20-forreview-minor pd20-forreview-minor

          People

          • Assignee:
            Unassigned
            Reporter:
            Nigel Deakin
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: