Hi
On 15/08/12 18:02, Marek Potociar wrote:
> 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
> o 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
>
At the moment, do you see @Suspended (as a parameter-level annotation)
redundant ? It does seem to me it is:
@GET
public String get(@Suspended AsyncResponse) {}
I mean, the runtime can decide what to do based on the fact that a given
method parameter type is AsyncResponse ?
The other question, what about the following style:
@GET
@Suspended
public String get() {}
This is how CXF JAX-WS implementation supports suspended invocations
(with the help of CXF UseAsyncMethod annotation).
Thanks, Sergey
>
> 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
> <mailto: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
>