On 2/1/2013 6:59 AM, Marek Potociar wrote:
>
> 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.
>
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
http://bill.burkecentral.com