users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: Re: Remove @ManagedAsync Re: Re: Re: Latest async API changes

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Wed, 15 Aug 2012 19:02:28 +0200

Experts,

While I disagree with most of what Bill is objecting to, I have not received any other real support for either side from you. So, since I do not feel strongly about having these features in JAX-RS now, to move out of this deadlock situation I have updated the async API proposal as follows:

removed all properties from @Suspended
the injected AsyncResponse is suspended indefinitely by default which may be changed using its programmatic API
removed ConnectionCallback from JAX-RS API
removed @ManagedAsync from JAX-RS API
added varargs versions of AsyncResponse.register() methods.
updated examples and javadoc accordingly

See the whole change here:
http://java.net/projects/jax-rs-spec/sources/git/revision/a864c50ab2a03e438b258f9b2ab53ecb9be3310d

Kind regards,
Marek

On Aug 10, 2012, at 7:41 PM, Bill Burke <bburke_at_redhat.com> wrote:

>
>
> On 8/10/2012 11:43 AM, Santiago Pericas-Geertsen wrote:
>>
>> On Aug 10, 2012, at 11:14 AM, Bill Burke wrote:
>>> On 8/9/2012 5:55 PM, Santiago Pericas-Geertsen wrote:
>>>>
>>>> On Aug 9, 2012, at 2:49 PM, Bill Burke wrote:
>>>>
>>>>>
>>>>>
>>>>> On 8/9/2012 12:06 PM, Marek Potociar wrote:
>>>>>>> On 8/8/2012 3:06 PM, Bill Burke wrote:
>>>>>>>> I don't agree with @ManagedAsync. A method annotated with @ManagedAsync
>>>>>>>> is executed in a separate thread? The servlet container is *already*
>>>>>>>> doing this so I don't see the point of this annotation.
>>>>>>
>>>>>> Apart from the fact that JAX-RS is not bound to run just on a servlet container, I believe you're also wrong when it comes to the assumption that a servlet is executed on a separate thread from the one that received the client connection. Servlet is (or at least can be) executed by exactly the same thread that received the client connection. (Because unless your servlet is async-dispatched, the client connection will close once the call to the servlet method terminates. IOW, async Servlet dispatching is not about async execution, it is about telling the Servlet container that it should not automatically close the client connection when the servlet call returns.) As you know the pool of these connection-handling threads is typically limited. And even if the servlet container had a special servlet execution thread pool, that pool would also be typically limited. Look at any async Servlet example - the request is either dispatched to a different servlet (with a possible s!
> pe!
>>> ci!
>>>>>>
>>>>>
>>>>> The performance benefit of @ManagedAsync is questionable because most production quality servlet containers know how to manage lots of concurrent connections very well. In fact, in most cases, using a completely separate thread to just marshall and send back the response on the wire would be detrimental to performance as it would involve context switching.
>>>>
>>>> I guess this depends a lot on the container's architecture. Sometimes, there's a max number of request threads configured in the container and you don't want to tie up one of those on a long running operation to avoid a denial of service.
>>>>
>>>
>>> I really don't think there is any gain by doing this. It's still a thread per connection to matter how you look at it. While you're not consuming a thread of the servlet container, you're consuming a thread of some other executor. You are just not doing anything new that the servlet container isn't already doing for you!
>>
>> Does your servlet container use an unbounded thread pool? If so, there won't be much difference. However, most servlet containers use a bounded thread pool. If that bound is reached and the CPU utilization is not maxed out, then using other threads will increase throughput as more connections will be accepted.
>>
>
> Can't you see it is the *SAME EXACT THING* and that there is nothing gained here? So instead of configuring and managing just one thread pool, you want users to managed and configure 2 thread pools? Just doesn't make sense...just add more threads to your servlet container's thread pool if CPU is not utilized and you have waiting HTTP requests.
>
>
>>>
>>>>> Also, since you're not providing any way to plug in an executor you're leaving *A LOT* up to the vendor implementation to provide configuration.
>>>>
>>>> Actually, this is something that we should probably add if we decide to go with this feature.
>>>>
>>>
>>> IMO, this is a really bad idea. Async HTTP is already an edge case
>>
>> Async HTTP is basis for implementing HTML5's SSE protocol, and that is quite useful actually.
>>
>
> HTML 5 applications are using web sockets, not vanilla HTTP to implement push protocols.
>
>
>>> , @ManagedAsync is even edgier than Async HTTP and I have very large doubts its actually useful. Application servers already have a means to manage servlet threads and connections, why are we adding yet another layer to do tje same exact thing? I just can't support this feature...
>>
>> We can already do this using an EJB resource class and @Asynchronous. I think the proposal was to support this for the non-EJB case. I would agree that is not a strong requirement for JAX-RS async, though.
>>
>
> Go back and read my other reply. @Asynchronous != @ManagedAsync. @Asynchronous is fire and forget, or returns a Future object. HTTP is not a fire and forget protocol. Neither do we have the luxury of dealing with a Future object on the client. You wouldn't be able to use @Asynchronous with a JAX-RS service.
> --
> Bill Burke
> JBoss, a division of Red Hat