javax.jms

## Interface JMSConsumer

- All Superinterfaces:
    AutoCloseable

      public interface JMSConsumer
      extends AutoCloseable

  A client using the simplified JMS API introduced for JMS 2.0 uses a `JMSConsumer` object to receive messages from a queue or topic. A `JMSConsumer` object may be created either created by passing a `Queue` or `Topic` object to one of the `createConsumer` methods on a `JMSContext`. or by passing a `Topic` object to one of the `createSharedConsumer` or `createDurableConsumer` methods on a `JMSContext`.

  A `JMSConsumer` can be created with a message selector. A message selector allows the client to restrict the messages delivered to the `JMSConsumer` to those that match the selector.

  A client may either synchronously receive a `JMSConsumer`'s messages or have the `JMSConsumer` asynchronously deliver them as they arrive.

  For synchronous receipt, a client can request the next message from a `JMSConsumer` using one of its `receive` methods. There are several variations of `receive` that allow a client to poll or wait for the next message.

  For asynchronous delivery, a client can register a `MessageListener` object with a `JMSConsumer`. As messages arrive at the `JMSConsumer`, it delivers them by calling the `MessageListener` 's `onMessage` method.

  It is a client programming error for a `MessageListener` to throw an exception.

  Since:
    JMS 2.0
  See Also:
    `JMSContext`

- - ### Method Summary

    Methods
    Modifier and Type | Method and Description
    --- | ---
    `void` | `close()` Closes the `JMSConsumer`.
    `MessageListener` | `getMessageListener()` Gets the `JMSConsumer`'s `MessageListener`.
    `String` | `getMessageSelector()` Gets this `JMSConsumer`'s message selector expression.
    `Message` | `receive()` Receives the next message produced for this `JMSConsumer`.
    `Message` | `receive(long timeout)` Receives the next message that arrives within the specified timeout interval.
    `<T> T` | `receiveBody(Class<T> c)` Receives the next message produced for this `JMSConsumer` and returns its body as an object of the specified type.
    `<T> T` | `receiveBody(Class<T> c, long timeout)` Receives the next message produced for this `JMSConsumer` that arrives within the specified timeout period and returns its body as an object of the specified type.
    `<T> T` | `receiveBodyNoWait(Class<T> c)` Receives the next message produced for this `JMSConsumer` if one is immediately available and returns its body as an object of the specified type.
    `Message` | `receiveNoWait()` Receives the next message if one is immediately available.
    `void` | `setMessageListener(MessageListener listener)` Sets the `JMSConsumer`'s `MessageListener`.

- - ### Method Detail

    - #### getMessageSelector

          String getMessageSelector()

      Gets this `JMSConsumer`'s message selector expression.
      Returns:
        this `JMSConsumer`'s message selector, or null if no message selector exists for the `JMSConsumer` (that is, if the message selector was not set or was set to null or the empty string)
      Throws:
        `JMSRuntimeException` - if the JMS provider fails to get the message selector due to some internal error.

    - #### getMessageListener

          MessageListener getMessageListener()
                                             throws JMSRuntimeException

      Gets the `JMSConsumer`'s `MessageListener`.

      This method must not be used in a Java EE web or EJB application. Doing so may cause a `JMSRuntimeException` to be thrown though this is not guaranteed.

      Returns:
        the `JMSConsumer`'s `MessageListener`, or null if one was not set
      Throws:
        `JMSRuntimeException` - if the JMS provider fails to get the `MessageListener` for one of the following reasons:
        - an internal error has occurred or
        - this method has been called in a Java EE web or EJB application (though it is not guaranteed that an exception is thrown in this case)
      See Also:
        `setMessageListener(javax.jms.MessageListener)`

    - #### setMessageListener

          void setMessageListener(MessageListener listener)
                                  throws JMSRuntimeException

      Sets the `JMSConsumer`'s `MessageListener`.

      Setting the `MessageListener` to null is the equivalent of unsetting the `MessageListener` for the `JMSConsumer`.

      The effect of calling this method while messages are being consumed by an existing listener or the `JMSConsumer` is being used to consume messages synchronously is undefined.

      This method must not be used in a Java EE web or EJB application. Doing so may cause a `JMSRuntimeException` to be thrown though this is not guaranteed.

      Parameters:
        `listener` - the listener to which the messages are to be delivered
      Throws:
        `JMSRuntimeException` - if the JMS provider fails to set the `JMSConsumer`'s `MessageListener` for one of the following reasons:
        - an internal error has occurred or
        - this method has been called in a Java EE web or EJB application (though it is not guaranteed that an exception is thrown in this case)
      See Also:
        `getMessageListener()`

    - #### receive

          Message receive()

      Receives the next message produced for this `JMSConsumer`.

      This call blocks indefinitely until a message is produced or until this `JMSConsumer` is closed.

      If this `receive` is done within a transaction, the JMSConsumer retains the message until the transaction commits.

      Returns:
        the next message produced for this `JMSConsumer`, or null if this `JMSConsumer` is concurrently closed
      Throws:
        `JMSRuntimeException` - if the JMS provider fails to receive the next message due to some internal error.

    - #### receive

          Message receive(long timeout)

      Receives the next message that arrives within the specified timeout interval.

      This call blocks until a message arrives, the timeout expires, or this `JMSConsumer` is closed. A `timeout` of zero never expires, and the call blocks indefinitely.

      Parameters:
        `timeout` - the timeout value (in milliseconds)
      Returns:
        the next message produced for this `JMSConsumer`, or null if the timeout expires or this `JMSConsumer` is concurrently closed
      Throws:
        `JMSRuntimeException` - if the JMS provider fails to receive the next message due to some internal error.

    - #### receiveNoWait

          Message receiveNoWait()

      Receives the next message if one is immediately available.
      Returns:
        the next message produced for this `JMSConsumer`, or null if one is not available
      Throws:
        `JMSRuntimeException` - if the JMS provider fails to receive the next message due to some internal error.

    - #### close

          void close()

      Closes the `JMSConsumer`.

      Since a provider may allocate some resources on behalf of a `JMSConsumer` outside the Java virtual machine, clients should close them when they are not needed. Relying on garbage collection to eventually reclaim these resources may not be timely enough.

      This call will block until a `receive` call in progress on this consumer has completed. A blocked `receive` call returns null when this consumer is closed.

      If this method is called whilst a message listener is in progress in another thread then it will block until the message listener has completed.

      This method may be called from a message listener's `onMessage` method on its own consumer. After this method returns the `onMessage` method will be allowed to complete normally.

      This method is the only `JMSConsumer` method that can be called concurrently.

      Specified by:
        `close` in interface `AutoCloseable`
      Throws:
        `JMSRuntimeException` - if the JMS provider fails to close the consumer due to some internal error.

    - #### receiveBody

          <T> T receiveBody(Class<T> c)

      Receives the next message produced for this `JMSConsumer` and returns its body as an object of the specified type. This method may be used to receive any type of message except for `StreamMessage` and `Message`, so long as the message has a body which is capable of being assigned to the specified type. This means that the specified class or interface must either be the same as, or a superclass or superinterface of, the class of the message body. If the message is not one of the supported types, or its body cannot be assigned to the specified type, or it has no body, then a `MessageFormatRuntimeException` is thrown.

      This method does not give access to the message headers or properties (such as the `JMSRedelivered` message header field or the `JMSXDeliveryCount` message property) and should only be used if the application has no need to access them.

      This call blocks indefinitely until a message is produced or until this `JMSConsumer` is closed.

      If this method is called within a transaction, the `JMSConsumer` retains the message until the transaction commits.

      The result of this method throwing a `MessageFormatRuntimeException` depends on the session mode:

      - `AUTO_ACKNOWLEDGE` or `DUPS_OK_ACKNOWLEDGE`: The JMS provider will behave as if the unsuccessful call to `receiveBody` had not occurred. The message will be delivered again before any subsequent messages.

        This is not considered to be redelivery and does not cause the `JMSRedelivered` message header field to be set or the `JMSXDeliveryCount` message property to be incremented.

      - `CLIENT_ACKNOWLEDGE`: The JMS provider will behave as if the call to `receiveBody` had been successful and will not deliver the message again.

        As with any message that is delivered with a session mode of `CLIENT_ACKNOWLEDGE`, the message will not be acknowledged until `acknowledge` is called on the `JMSContext`. If an application wishes to have the failed message redelivered, it must call `recover` on the `JMSContext`. The redelivered message's `JMSRedelivered` message header field will be set and its `JMSXDeliveryCount` message property will be incremented.

      - Transacted session: The JMS provider will behave as if the call to `receiveBody` had been successful and will not deliver the message again.

        As with any message that is delivered in a transacted session, the transaction will remain uncommitted until the transaction is committed or rolled back by the application. If an application wishes to have the failed message redelivered, it must roll back the transaction. The redelivered message's `JMSRedelivered` message header field will be set and its `JMSXDeliveryCount` message property will be incremented.

      Parameters:
        `c` - The type to which the body of the next message should be assigned.
        If the next message is expected to be a `TextMessage` then this should be set to `String.class` or another class to which a `String` is assignable.
        If the next message is expected to be a `ObjectMessage` then this should be set to `java.io.Serializable.class` or another class to which the body is assignable.
        If the next message is expected to be a `MapMessage` then this should be set to `java.util.Map.class` (or `java.lang.Object.class`).
        If the next message is expected to be a `BytesMessage` then this should be set to `byte[].class` (or `java.lang.Object.class`).
      Returns:
        the body of the next message produced for this `JMSConsumer`, or null if this `JMSConsumer` is concurrently closed
      Throws:
        `MessageFormatRuntimeException` -
        - if the message is not one of the supported types listed above
        - if the message body cannot be assigned to the specified type
        - if the message has no body
        - if the message is an `ObjectMessage` and object deserialization fails.
        `JMSRuntimeException` - if the JMS provider fails to receive the next message due to some internal error

    - #### receiveBody

          <T> T receiveBody(Class<T> c,
                          long timeout)

      Receives the next message produced for this `JMSConsumer` that arrives within the specified timeout period and returns its body as an object of the specified type. This method may be used to receive any type of message except for `StreamMessage` and `Message`, so long as the message has a body which is capable of being assigned to the specified type. This means that the specified class or interface must either be the same as, or a superclass or superinterface of, the class of the message body. If the message is not one of the supported types, or its body cannot be assigned to the specified type, or it has no body, then a `MessageFormatRuntimeException` is thrown.

      This method does not give access to the message headers or properties (such as the `JMSRedelivered` message header field or the `JMSXDeliveryCount` message property) and should only be used if the application has no need to access them.

      This call blocks until a message arrives, the timeout expires, or this `JMSConsumer` is closed. A timeout of zero never expires, and the call blocks indefinitely.

      If this method is called within a transaction, the `JMSConsumer` retains the message until the transaction commits.

      The result of this method throwing a `MessageFormatRuntimeException` depends on the session mode:

      - `AUTO_ACKNOWLEDGE` or `DUPS_OK_ACKNOWLEDGE`: The JMS provider will behave as if the unsuccessful call to `receiveBody` had not occurred. The message will be delivered again before any subsequent messages.

        This is not considered to be redelivery and does not cause the `JMSRedelivered` message header field to be set or the `JMSXDeliveryCount` message property to be incremented.

      - `CLIENT_ACKNOWLEDGE`: The JMS provider will behave as if the call to `receiveBody` had been successful and will not deliver the message again.

        As with any message that is delivered with a session mode of `CLIENT_ACKNOWLEDGE`, the message will not be acknowledged until `acknowledge` is called on the `JMSContext`. If an application wishes to have the failed message redelivered, it must call `recover` on the `JMSContext`. The redelivered message's `JMSRedelivered` message header field will be set and its `JMSXDeliveryCount` message property will be incremented.

      - Transacted session: The JMS provider will behave as if the call to `receiveBody` had been successful and will not deliver the message again.

        As with any message that is delivered in a transacted session, the transaction will remain uncommitted until the transaction is committed or rolled back by the application. If an application wishes to have the failed message redelivered, it must roll back the transaction. The redelivered message's `JMSRedelivered` message header field will be set and its `JMSXDeliveryCount` message property will be incremented.

      Parameters:
        `c` - The type to which the body of the next message should be assigned.
        If the next message is expected to be a `TextMessage` then this should be set to `String.class` or another class to which a `String` is assignable.
        If the next message is expected to be a `ObjectMessage` then this should be set to `java.io.Serializable.class` or another class to which the body is assignable.
        If the next message is expected to be a `MapMessage` then this should be set to `java.util.Map.class` (or `java.lang.Object.class`).
        If the next message is expected to be a `BytesMessage` then this should be set to `byte[].class` (or `java.lang.Object.class`).
      Returns:
        the body of the next message produced for this `JMSConsumer`, or null if the timeout expires or this `JMSConsumer` is concurrently closed
      Throws:
        `MessageFormatRuntimeException` -
        - if the message is not one of the supported types listed above
        - if the message body cannot be assigned to the specified type
        - if the message has no body
        - if the message is an `ObjectMessage` and object deserialization fails.
        `JMSRuntimeException` - if the JMS provider fails to receive the next message due to some internal error

    - #### receiveBodyNoWait

          <T> T receiveBodyNoWait(Class<T> c)

      Receives the next message produced for this `JMSConsumer` if one is immediately available and returns its body as an object of the specified type. This method may be used to receive any type of message except for `StreamMessage` and `Message`, so long as the message has a body which is capable of being assigned to the specified type. This means that the specified class or interface must either be the same as, or a superclass or superinterface of, the class of the message body. If the message is not one of the supported types, or its body cannot be assigned to the specified type, or it has no body, then a `MessageFormatRuntimeException` is thrown.

      This method does not give access to the message headers or properties (such as the `JMSRedelivered` message header field or the `JMSXDeliveryCount` message property) and should only be used if the application has no need to access them.

      If a message is not immediately available null is returned.

      If this method is called within a transaction, the `JMSConsumer` retains the message until the transaction commits.

      The result of this method throwing a `MessageFormatRuntimeException` depends on the session mode:

      - `AUTO_ACKNOWLEDGE` or `DUPS_OK_ACKNOWLEDGE`: The JMS provider will behave as if the unsuccessful call to `receiveBodyNoWait` had not occurred. The message will be delivered again before any subsequent messages.

        This is not considered to be redelivery and does not cause the `JMSRedelivered` message header field to be set or the `JMSXDeliveryCount` message property to be incremented.

      - `CLIENT_ACKNOWLEDGE`: The JMS provider will behave as if the call to `receiveBodyNoWait` had been successful and will not deliver the message again.

        As with any message that is delivered with a session mode of `CLIENT_ACKNOWLEDGE`, the message will not be acknowledged until `acknowledge` is called on the `JMSContext`. If an application wishes to have the failed message redelivered, it must call `recover` on the `JMSContext`. The redelivered message's `JMSRedelivered` message header field will be set and its `JMSXDeliveryCount` message property will be incremented.

      - Transacted session: The JMS provider will behave as if the call to `receiveBodyNoWait` had been successful and will not deliver the message again.

        As with any message that is delivered in a transacted session, the transaction will remain uncommitted until the transaction is committed or rolled back by the application. If an application wishes to have the failed message redelivered, it must roll back the transaction. The redelivered message's `JMSRedelivered` message header field will be set and its `JMSXDeliveryCount` message property will be incremented.

      Parameters:
        `c` - The type to which the body of the next message should be assigned.
        If the next message is expected to be a `TextMessage` then this should be set to `String.class` or another class to which a `String` is assignable.
        If the next message is expected to be a `ObjectMessage` then this should be set to `java.io.Serializable.class` or another class to which the body is assignable.
        If the next message is expected to be a `MapMessage` then this should be set to `java.util.Map.class` (or `java.lang.Object.class`).
        If the next message is expected to be a `BytesMessage` then this should be set to `byte[].class` (or `java.lang.Object.class`).
      Returns:
        the body of the next message produced for this `JMSConsumer`, or null if one is not immediately available or this `JMSConsumer` is concurrently closed
      Throws:
        `MessageFormatRuntimeException` -
        - if the message is not one of the supported types listed above
        - if the message body cannot be assigned to the specified type
        - if the message has no body
        - if the message is an `ObjectMessage` and object deserialization fails.
        `JMSRuntimeException` - if the JMS provider fails to receive the next message due to some internal error

Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.