Skip to main content

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Spec's reference of EJB's @Asynchronous is incorrect

  • From: Marek Potociar <marek.potociar@...>
  • To: jsr339-experts@...
  • Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Spec's reference of EJB's @Asynchronous is incorrect
  • Date: Fri, 1 Feb 2013 12:59:33 +0100


On Feb 1, 2013, at 1:31 AM, Bill Burke <bburke@...> wrote:

> 
> 
> On 1/30/2013 4:24 PM, Marek Potociar wrote:
>
>> On Jan 30, 2013, at 8:54 PM, Bill Burke <bburke@...
>> <mailto:bburke@...>> 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



[jsr339-experts] Re: [jax-rs-spec users] Re: Spec's reference of EJB's @Asynchronous is incorrect

Bill Burke 02/01/2013

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Spec's reference of EJB's @Asynchronous is incorrect

Marek Potociar 02/01/2013

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Spec's reference of EJB's @Asynchronous is incorrect

Bill Burke 02/01/2013
 
 
Close
loading
Please Confirm
Close