On Oct 1, 2012, at 1:46 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>
> On Oct 1, 2012, at 10:27 PM, Marek Potociar wrote:
>
>>
>> On Sep 30, 2012, at 1:30 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>>
>>> All,
>>>
>>> based on the implementation experience with the Async API to date, can you provide advice on what a developer should consider a 'long running operation'?
>>>
>>> What operations are usually long running enough to see a server performance or capacity gain when switching to the async API?
>>
>> I guess it also depends on your container I/O thread-pool setup, and the expected request rate. In general, anything that involves another I/O operation (file, DB, network) is a good candidate for switching to async API.
>
> Which makes async a good candidate for JAX-RS runtime default behaviour :-) Given that resource methods usually do network stuff or file IO...
Again, it depends on the underlying container...
>
> I am worried a bit about the cost of the additional thread creation - have you considered/tried combining JAX-RS async with non-blocking IO? (Though maybe that's nonsense. It's late...)
It's more a question of thread context switching than thread creation as typically you would be using a thread pool. As for NIO, we have it on our radar, but it would be IMO premature to attempt standardization without a hands-on prior experience... So you may first expect to see some proprietary API attempts.
>
>> But it's just a rule of thumb...
>
>
> Seems to depend on the container impl., too.
>
> Thanks for getting back during Java One!
You're welcome! :)
Are you somewhere around?
Marek
>
> Jan
>
>
>
>> HTH,
>> Marek
>>
>>>
>>> File IO?
>>> JPA data read?
>>> JPA data write?
>>> Upstream HTTP request?
>>> ...
>>>
>>>
>>> Jan
>>
>