Skip to main content

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

  • From: Bill Burke <bburke@...>
  • To: jsr339-experts@...
  • Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Spec's reference of EJB's @Asynchronous is incorrect
  • Date: Fri, 01 Feb 2013 18:38:13 -0500

On 2/1/2013 6:59 AM, Marek Potociar wrote:

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.

I'm not mixing up anything here. It is you that are confused. EJB's @Asynchronous was designed for async clients, not for thread pool management.

I don't see how you can go from "EJB @Asynchronous + JAX-RS should be illegal" to inferring that I think using AsyncResponse with executors is a bad idea or should be disallowed. Whether or not JAX-RS AsyncResponse can be used with Executors (they can) has nothing to do with my argument. EJB @Asynchronous + 'void' does not have a callback because it is fire-and-forget. AsyncResponse is basically a callback to send back an HTTP response to the client.

If instead, EJB @Asynchronous immediately sent back a 202, Accepted to the client before it processed the EJB method, this would make a lot of sense and wouldn't break the EJB contract.

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.

I'm just sick and tired of giving you reason after reason why this pattern of moving response processing from one thread to another is pointless (and often detrimental) without being able to specify thread priorities, queue sizes, etc. Things that MDBs and Executors provide. Something EJB @Asynchronous (and @ManagedAsync) does not...

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?

Haven't I spelled it out over and over? A better sample is no sample: EJB @Asynchronous with JAX-RS should be illegal.

Bill Burke
JBoss, a division of Red Hat

[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
Please Confirm