jms-spec
  1. jms-spec
  2. JMS_SPEC-66

Define how MessageConsumer.receive should handle a thread interrupt

    Details

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

      Description

      The Java SE API allows an application to interrupt a running thread by calling the interrupt method on the Thread object.

      I'm logging this issue to raise the question of whether JMS should define how a JMS provider should handle a thread interrupt during a call to MessageConsumer.receive() or MessageConsumer.receive(timeout), which will both block whilst waiting for a message to arrive.

      There's a useful article by Brian Goetz here:
      http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html

      Possibilities are:

      1. Leave this up to the JMS provider (which is the current situation in JMS 1.1)
      2. Define that a thread interrupt should cause the receive method to throw a JMSException
      3. Define that a thread interrupt should cause the receive method to throw a InterruptedException
      4. Define that a thread interrupt should be ignored

      Note that it would not be possible to change the signature of the existing receive methods (as in (3)) since this would break backwards compatibility.

      In cases 1,2 and 4 (the ones that don't throw a InterruptedException) Brian Goetz's article recommends that the method should re-enable the interrupted status of the thread (even if the interrupt was swallowed or converted a JMSException) to allow the calling code to detect whether an interrupt had occurred.

      In logging this issue I'm not proposing any change, but the topic is worth recording and I'd welcome comments.

        Activity

        Hide
        brecht_yperman added a comment -

        Having encountered this issue with JMS 1.1 and OpenMQ, I'd personally prefer option 2.

        MessageConsumer.receive() is an operation very similar to a blocking read, described in the API

        "If this thread is blocked in an I/O operation upon an interruptible channel then the channel will be closed, the thread's interrupt status will be set, and the thread will receive a ClosedByInterruptException."
        http://docs.oracle.com/javase/6/docs/api/java/lang/Thread.html#interrupt()

        I also think, but this is of course guessing, that most JMS clients do a blocking socket read anyway, so they can easily handle the InterruptedException thrown by that read.

        Just my two cents.

        Show
        brecht_yperman added a comment - Having encountered this issue with JMS 1.1 and OpenMQ, I'd personally prefer option 2. MessageConsumer.receive() is an operation very similar to a blocking read, described in the API "If this thread is blocked in an I/O operation upon an interruptible channel then the channel will be closed, the thread's interrupt status will be set, and the thread will receive a ClosedByInterruptException." http://docs.oracle.com/javase/6/docs/api/java/lang/Thread.html#interrupt( ) I also think, but this is of course guessing, that most JMS clients do a blocking socket read anyway, so they can easily handle the InterruptedException thrown by that read. Just my two cents.
        Hide
        Nigel Deakin added a comment -

        This issue will be considered by the expert group for possible inclusion in the JMS 2.0 public draft. Tagging appropriately.

        Show
        Nigel Deakin added a comment - This issue will be considered by the expert group for possible inclusion in the JMS 2.0 public draft. Tagging appropriately.
        Hide
        axel_podehl added a comment -

        I would prefer 3 (throw InterruptedException)- if it wouldn't break the API.
        So choice 2 (throw JMSException) is the second best alternative

        Probably the JMS Provider should set JMSException.setLinkedException() to be the InterruptedException

        Show
        axel_podehl added a comment - I would prefer 3 (throw InterruptedException)- if it wouldn't break the API. So choice 2 (throw JMSException) is the second best alternative Probably the JMS Provider should set JMSException.setLinkedException() to be the InterruptedException

          People

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

            Dates

            • Created:
              Updated: