> >>> The target of decoupling can be reach rather easily:
> >>> @GET Future<MyEntity> getAsync() { /* Use Executor to return
> Future
> >> instance */ }
> >>> In case the return type is "Future<?>" the JAX-RS runtime can
> safely
> >>> assume that the method will return without providing a physical
> result.
> >>> The thread can return, and as soon as the Future is provided it can
> >>> pick up work again and send back the response. No need for any
> >>> additional complexity or annotations.
> >> Does it mean that some JAX-RS thread has to be blocked while waiting
> >> for the response? Also, if we decide to go with
> >> your simplified proposal, how would you later evolve it into
> something
> >> suitable for a Pub/Sub support?
> >
> > The calling thread is not getting blocked, as the method obviously
> returns immediately having a Future in hands. The JAX-RS engine sees
> the fact that it is a Future and knows "Hey, the result will be
> provided later, so let's put that one on a stack for now and continue
> with some different work.". In fact, the identification of Future
> allows the same thread to do other work instead of getting blocked. It
> can be used to answer a different response for example, or for any
> other asynchronous work that is queued by the engine (like asynchronous
> logging in the background for example, or re-balancing work queues).
> The creation of the future is done by an ExecutorService, hopefully one
> provided by the container, so the container admin has control over
> number of threads and priorities etc. Certainly we could allow private
> Executors (Java SE, created manually) also, but certainly a shared
> ExecutorService is more efficient.
> >
>
> With your proposal, the container is going to have to block/poll on a
> future.get(). IMO, let the application interact with a callback
> interface. Its much simpler for both the container and application
> implementation.
We could define that a JAX-RS-provided ExecutorService must be used to create the Futures. In that case, the Future implementation can trigger a callback in the container to send back the result. No block/poll needed then.