On Feb 1, 2013, at 1:31 AM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> 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?
IMO, you're mixing "no response from processing" with "no response to HTTP request". IMO, a processing facility can produce a response to a HTTP request as a side effect (by updating the state of the AsyncResponse based on the processing outcome) and not produce any other intrinsic response at the same time. What you are saying is that AsyncResponse should not even be used with Executors and Runnable tasks and that HTTP response should not be returned from Runnable tasks, because these, too, are fire&forget. That's a nonsense. Fire&forget tasks do have "side-effects". Otherwise they would be futile.
>
>>> 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....
Please, stop acting like you know it all and the rest of us just don't get it. Do not assume that I'm not trying to see your point because I'm just too stubborn to admit that I could be wrong. That's certainly not the case and I hope I demonstrated it several times even in this forum. I truly disagree with you in this case and repeating your mantra is not going to change it. Mixing intrinsic response of a task with a HTTP response as a result of updating input parameter state during the processing of the task is still a mistake in my view.
>
>> 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.
Maybe that way we can close this down without heated debates about what's right and wrong programming model for asynchronous EJBs. Why don't you come up with a better sample that is in your view more appropriate for Java EE and we can consider switching it?
Marek
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com