On 1/30/2013 4:24 PM, Marek Potociar wrote:
>
> On Jan 30, 2013, at 8:54 PM, Bill Burke <bburke_at_redhat.com
> <mailto:bburke_at_redhat.com>> wrote:
>
>>
>>
>> On 1/30/2013 11:32 AM, Marek Potociar wrote:
>>> I'm not sure I follow how the EJB async "fire-and-forget" nature
>>> relates to HTTP.
>>
>> Exactly my point, it doesn't relate, so you can't use it with JAX-RS.
>
> The statement above a nice example of "non sequitur" fallacy IMO. One
> can further expand the above ad absurdum by stating that thread pools do
> not relate to HTTP, therefore you should not use thread pools with
> JAX-RS, or when doing HTTP processing in general...
>
Actually re-read again what I typed. @Asynchronous + 'void' is
fire-and-forget. The expected behavior is no response. It is pretty
much similar to oneway in CORBA. HTTP requires a response. Why is that
so hard to grok here?
>> HTTP expects a response, 'void' + @Asychronous, there is no response
>> for EJB clients.
>>
>>> All we are saying is that the HTTP response is returned on a
>>> different thread that the one received the request.
>>
>> Back to our old argument, so I won't go there...
>>
>>> Async EJBs is one way how to delegate request processing to another
>>> (managed) thread in a JEE container.
>>
>> Wrong. Async EJBs is so that the client execute one or more tasks in
>> the background. It has nothing to do with managed threads in the Java
>> EE container other than a possible implementation detail.
>
> Has anything changed? I still operate with the assumption that
> off-loading long-running request processing to a different thread (or,
> if you like, execution facility in general) is a valid use case for
> asynchronous HTTP request processing. Therefore offloading the
> processing to a facility that is able to execute the task "in the
> background" is IMO a valid approach.
>
Although offloading is pointless without thread priorities, it is
orthogonal. fire-and-forget means no response. HTTP requires a
response. I'll keep repeating it until you get it....
> You can do:
>
> @Stateless
> public class MyEjb {
> @Asynchronous
> public void process(AsyncResponse response) {
> ...
> response.resume(...);
> }
> }
>
> @Path("resource")
> public class MyResource {
> @EJB private MyEjb ejb;
>
> @GET
> public void process(@Suspended AsyncResponse response) {
> ejb.process(response);
> }
> }
>
> So why would you want to prevent doing directly:
>
> @Stateless
> @Path("resource")
> public class MyEjb {
>
> @Asynchronous
> @GET
> public void process(@Suspended AsyncResponse response) {
> ...
> response.resume(...);
> }
> }
>
> Both notations above are expected to do essentially the same thing. So
> why is it a problem to allow the shorter version? Why would we want our
> users to write more code?
>
Since there is no concept of thread priorities, the whole practice is
completely useless. You are better off delegating to an MDB or
Executor, which actually allows you to set priorities, manage flows, etc.
All and all, beyond it breaking the @Asynchronous contract, i don't want
this example in the spec because IMNSHO, it is an anti-pattern and
encouraging people to do things that they shouldn't.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com