On Jan 30, 2013, at 8:54 PM, Bill Burke <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...
> 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.
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?
I would understand if you were saying that one should not use async EJBs without async JAX-RS. That would make sense to me.
Marek