On Jul 25, 2011, at 2:55 PM, Bill Burke wrote:
>
>
> On 7/25/11 2:04 PM, Markus KARG wrote:
>> Marek,
>>
>>>> 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().
Exactly. -1 on any solution that requires any form of polling …
-- Santiago
> IMO, let the application interact with a callback interface. Its much simpler for both the container and application implementation.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com