javax.ws.rs.container

## Interface AsyncResponse

- All Known Subinterfaces:
    ResteasyAsynchronousResponse
  All Known Implementing Classes:
    AbstractAsynchronousResponse, SynchronousExecutionContext.SynchronousAsynchronousResponse

      public interface AsyncResponse

  An injectable JAX-RS asynchronous response that provides means for asynchronous server side response processing.

  A new instance of `AsyncResponse` may be injected into a `resource or sub-resource method` parameter using the `@Suspend` annotation.

  Each asynchronous response instance is bound to the running request and can be used to asynchronously provide the request processing result or otherwise manipulate the suspended client connection. The available operations include:
  - updating suspended state data (time-out value, response ...)
  - resuming the suspended request processing
  - canceling the suspended request processing

  Following example demonstrates the use of the `AsyncResponse` for asynchronous HTTP request processing:

       @Path("/messages/next")
       public class MessagingResource {
           private static final BlockingQueue<AsyncResponse> suspended =
                   new ArrayBlockingQueue<AsyncResponse>(5);

           @GET
           public void readMessage(@Suspended AsyncResponse ar) throws InterruptedException {
               suspended.put(ar);
           }

           @POST
           public String postMessage(final String message) throws InterruptedException {
               final AsyncResponse ar = suspended.take();
               ar.resume(message); // resumes the processing of one GET request
               return "Message sent";
           }
       }

  If the asynchronous response was suspended with a positive timeout value, and has not been explicitly resumed before the timeout has expired, the processing will be resumed once the specified timeout threshold is reached, provided a positive timeout value was set on the response.

  By default a timed-out asynchronous response is resumed with a `WebApplicationException` that has `HTTP 503 (Service unavailable)` error response status code set. This default behavior may be overridden by `setting` a custom `time-out handler`.

  Since:
    2.0
  Author:
    Marek Potociar

- - ### Field Summary

    Fields
    Modifier and Type | Field and Description
    --- | ---
    `static long` | `NO_TIMEOUT` Constant specifying no suspend timeout value.

  - ### Method Summary

    Methods
    Modifier and Type | Method and Description
    --- | ---
    `boolean` | `cancel()` Cancel the suspended request processing.
    `boolean` | `cancel(Date retryAfter)` Cancel the suspended request processing.
    `boolean` | `cancel(int retryAfter)` Cancel the suspended request processing.
    `boolean` | `isCancelled()` Check if the asynchronous response instance has been cancelled.
    `boolean` | `isDone()` Check if the processing of a request this asynchronous response instance belongs to has finished.
    `boolean` | `isSuspended()` Check if the asynchronous response instance is in a suspended state.
    `Collection<Class<?>>` | `register(Class<?> callback)` Register an asynchronous processing lifecycle callback class to receive lifecycle events for the asynchronous response based on the implemented callback interfaces.
    `Map<Class<?>,Collection<Class<?>>>` | `register(Class<?> callback, Class<?>... callbacks)` Register asynchronous processing lifecycle callback classes to receive lifecycle events for the asynchronous response based on the implemented callback interfaces.
    `Collection<Class<?>>` | `register(Object callback)` Register an asynchronous processing lifecycle callback instance to receive lifecycle events for the asynchronous response based on the implemented callback interfaces.
    `Map<Class<?>,Collection<Class<?>>>` | `register(Object callback, Object... callbacks)` Register an asynchronous processing lifecycle callback instances to receive lifecycle events for the asynchronous response based on the implemented callback interfaces.
    `boolean` | `resume(Object response)` Resume the suspended request processing using the provided response data.
    `boolean` | `resume(Throwable response)` Resume the suspended request processing using the provided throwable.
    `boolean` | `setTimeout(long time, TimeUnit unit)` Set/update the suspend timeout.
    `void` | `setTimeoutHandler(TimeoutHandler handler)` Set/replace a time-out handler for the suspended asynchronous response.

- - ### Field Detail

    - #### NO_TIMEOUT

          static final long NO_TIMEOUT

      Constant specifying no suspend timeout value.
      See Also:
        Constant Field Values

  - ### Method Detail

    - #### resume

          boolean resume(Object response)

      Resume the suspended request processing using the provided response data. The provided response data can be of any Java type that can be returned from a `JAX-RS resource method`.

      The asynchronous response must be still in a `suspended` state for this method to succeed.

      By executing this method, the request is guaranteed to complete either successfully or with an error. The data processing by the JAX-RS runtime follows the same path as it would for the response data returned synchronously by a JAX-RS resource, except that unmapped exceptions are not re-thrown by JAX-RS runtime to be handled by a hosting I/O container. Instead, any unmapped exceptions are propagated to the hosting I/O container via a container-specific callback mechanism. Depending on the container implementation, propagated unmapped exceptions typically result in an error status being sent to the client and/or the connection being closed.

      Parameters:
        `response` - data to be sent back in response to the suspended request.
      Returns:
        `true` if the request processing has been resumed, returns `false` in case the request processing is not `suspended` and could not be resumed.
      See Also:
        `resume(Throwable)`

    - #### resume

          boolean resume(Throwable response)

      Resume the suspended request processing using the provided throwable. For the provided throwable same rules apply as for an exception thrown by a `JAX-RS resource method`.

      By executing this method, the request is guaranteed to complete either successfully or with an error. The throwable processing by the JAX-RS runtime follows the same path as it would for the response data returned synchronously by a JAX-RS resource, except that unmapped exceptions are not re-thrown by JAX-RS runtime to be handled by a hosting I/O container. Instead, any unmapped exceptions are propagated to the hosting I/O container via a container-specific callback mechanism. Depending on the container implementation, propagated unmapped exceptions typically result in an error status being sent to the client and/or the connection being closed.

      Parameters:
        `response` - an exception to be raised in response to the suspended request.
      Returns:
        `true` if the response has been resumed, returns `false` in case the response is not `suspended` and could not be resumed.
      See Also:
        `resume(Object)`

    - #### cancel

          boolean cancel()

      Cancel the suspended request processing.

      When a request processing is cancelled using this method, the JAX-RS implementation MUST indicate to the client that the request processing has been cancelled by sending back a `HTTP 503 (Service unavailable)` error response.

      Invoking a `cancel(...)` method multiple times to cancel request processing has the same effect as canceling the request processing only once. Invoking a `cancel(...)` method on an asynchronous response instance that has already been cancelled or resumed has no effect and the method call is ignored while returning `true`, in case the request has been cancelled previously. Otherwise, in case the request has been resumed regularly (using a `resume(...) method`) or resumed due to a time-out, method returns `false`.

      Returns:
        `true` if the request processing has been cancelled, returns `false` in case the request processing is not `suspended` and could not be cancelled and is not `cancelled` already.
      See Also:
        `cancel(int)`, `cancel(java.util.Date)`

    - #### cancel

          boolean cancel(int retryAfter)

      Cancel the suspended request processing.

      When a request processing is cancelled using this method, the JAX-RS implementation MUST indicate to the client that the request processing has been cancelled by sending back a `HTTP 503 (Service unavailable)` error response with a `Retry-After` header set to the value provided by the method parameter.

      Invoking a `cancel(...)` method multiple times to cancel request processing has the same effect as canceling the request processing only once. Invoking a `cancel(...)` method on an asynchronous response instance that has already been cancelled or resumed has no effect and the method call is ignored while returning `true`, in case the request has been cancelled previously. Otherwise, in case the request has been resumed regularly (using a `resume(...) method`) or resumed due to a time-out, method returns `false`.

      Parameters:
        `retryAfter` - a decimal integer number of seconds after the response is sent to the client that indicates how long the service is expected to be unavailable to the requesting client.
      Returns:
        `true` if the request processing has been cancelled, returns `false` in case the request processing is not `suspended` and could not be cancelled and is not `cancelled` already.
      See Also:
        `cancel()`, `cancel(java.util.Date)`

    - #### cancel

          boolean cancel(Date retryAfter)

      Cancel the suspended request processing.

      When a request processing is cancelled using this method, the JAX-RS implementation MUST indicate to the client that the request processing has been cancelled by sending back a `HTTP 503 (Service unavailable)` error response with a `Retry-After` header set to the value provided by the method parameter.

      Invoking a `cancel(...)` method multiple times to cancel request processing has the same effect as canceling the request processing only once. Invoking a `cancel(...)` method on an asynchronous response instance that has already been cancelled or resumed has no effect and the method call is ignored while returning `true`, in case the request has been cancelled previously. Otherwise, in case the request has been resumed regularly (using a `resume(...) method`) or resumed due to a time-out, method returns `false`.

      Parameters:
        `retryAfter` - a date that indicates how long the service is expected to be unavailable to the requesting client.
      Returns:
        `true` if the request processing has been cancelled, returns `false` in case the request processing is not `suspended` and could not be cancelled and is not `cancelled` already.
      See Also:
        `cancel()`, `cancel(int)`

    - #### isSuspended

          boolean isSuspended()

      Check if the asynchronous response instance is in a suspended state. Method returns `true` if this asynchronous response is still suspended and has not finished processing yet (either by resuming or canceling the response).
      Returns:
        `true` if this asynchronous response is in a suspend state, `false` otherwise.
      See Also:
        `isCancelled()`, `isDone()`

    - #### isCancelled

          boolean isCancelled()

      Check if the asynchronous response instance has been cancelled. Method returns `true` if this asynchronous response has been canceled before completion.
      Returns:
        `true` if this task was canceled before completion.
      See Also:
        `isSuspended()`, `isDone()`

    - #### isDone

          boolean isDone()

      Check if the processing of a request this asynchronous response instance belongs to has finished. Method returns `true` if the processing of a request this asynchronous response is bound to is finished.

      The request processing may be finished due to a normal termination, a suspend timeout, or cancellation -- in all of these cases, this method will return `true`.

      Returns:
        `true` if this execution context has finished processing.
      See Also:
        `isSuspended()`, `isCancelled()`

    - #### setTimeout

          boolean setTimeout(long time,
                           TimeUnit unit)

      Set/update the suspend timeout.

      The new suspend timeout values override any timeout value previously specified. The asynchronous response must be still in a `suspended` state for this method to succeed.

      Parameters:
        `time` - suspend timeout value in the give time `unit`. Value lower or equal to 0 causes the context to suspend indefinitely.
        `unit` - suspend timeout value time unit.
      Returns:
        `true` if the suspend time out has been set, returns `false` in case the request processing is not in the `suspended` state.

    - #### setTimeoutHandler

          void setTimeoutHandler(TimeoutHandler handler)

      Set/replace a time-out handler for the suspended asynchronous response.

      The time-out handler will be invoked when the suspend period of this asynchronous response times out. The job of the time-out handler is to resolve the time-out situation by either

      - resuming the suspended response
      - cancelling the suspended response
      - extending the suspend period by setting a new suspend time-out

      Note that in case the response is suspended `indefinitely`, the time-out handler may never be invoked.

      Parameters:
        `handler` - response time-out handler.

    - #### register

          Collection<Class<?>> register(Class<?> callback)

      Register an asynchronous processing lifecycle callback class to receive lifecycle events for the asynchronous response based on the implemented callback interfaces.
      Parameters:
        `callback` - callback class.
      Returns:
        collection of registered callback interfaces. If the callback class does not implement any recognized callback interfaces, the returned collection will be empty.
      Throws:
        `NullPointerException` - in case the callback class is `null`.

    - #### register

          Map<Class<?>,Collection<Class<?>>> register(Class<?> callback,
                                                    Class<?>... callbacks)

      Register asynchronous processing lifecycle callback classes to receive lifecycle events for the asynchronous response based on the implemented callback interfaces.
      Parameters:
        `callback` - callback class.
        `callbacks` - additional callback classes.
      Returns:
        map of registered classes and the callback interfaces registered for each class. If a callback class does not implement any recognized callback interfaces, the associated collection of registered interfaces for the class will be empty.
      Throws:
        `NullPointerException` - in case any of the callback classes is `null`.

    - #### register

          Collection<Class<?>> register(Object callback)

      Register an asynchronous processing lifecycle callback instance to receive lifecycle events for the asynchronous response based on the implemented callback interfaces.
      Parameters:
        `callback` - callback instance implementing one or more of the recognized callback interfaces.
      Returns:
        collection of registered callback interfaces. If the callback class does not implement any recognized callback interfaces, the returned collection will be empty.
      Throws:
        `NullPointerException` - in case the callback instance is `null`.

    - #### register

          Map<Class<?>,Collection<Class<?>>> register(Object callback,
                                                    Object... callbacks)

      Register an asynchronous processing lifecycle callback instances to receive lifecycle events for the asynchronous response based on the implemented callback interfaces.
      Parameters:
        `callback` - callback instance.
        `callbacks` - additional callback instances.
      Returns:
        map of registered classes and the callback interfaces registered for each class. If a callback class does not implement any recognized callback interfaces, the associated collection of registered interfaces for the class will be empty.
      Throws:
        `NullPointerException` - in case any of the callback instances is `null`.

Copyright © 2014. All Rights Reserved.