Sounds good, the unmapped/escaped exception must not cause blocking the response, so yeah, please create a test

I see a test testUnmappedAfterTimeout which asserts 500 is returned. This is a case where the current async response is suspended for some time and when it returns the unmapped exception is thrown. Perhaps when the exception escapes immediately then something needs to be tweaked

Cheers, Sergey
On 11/01/16 11:56, Benson Margulies wrote:
On Mon, Jan 11, 2016 at 6:49 AM, Sergey Beryozkin <sberyoz...@gmail.com>
wrote:

Hi Benson
On 11/01/16 11:42, Benson Margulies wrote:

Sergey,

I annotate @Suspended. So it is suspended on the first call.

It is not, believe me :-) because this is how I implemented it.
The runtime does not have to physically suspend a call, given that the
method can immediately call AsyncResponse.resume(). JAXRSInvoker will only
suspend the thread if no resume/cancel was called by the time the method
returns. The runtimes are allowed to optimize like this.


I think that perhaps we're using the word 'suspended' in two different
ways? I'm only meaning that the response object itself thinks it's
suspended. However, it's not important. If it's supposed to handle _thrown_
exceptions in the first call, I'll make a branch with a test case, because
what I saw what is that it hung.




The quote I read from the spec says that returned values from @Suspended
calls are ignored. It did not say what the spec says about exceptions from
those calls. If they are also supposed to be ignored, then a big fat WARN
log message would be what I have in mind.

The exceptions escaped from a method are supposed to be caught, 'the
returned values are ignored' is probably a reference to a 'void' return
type, but of course a method can immediately do
asyncResponse.resume(myResponse).


Yes, it says that you must use 'void' and if you return something else it
will be ignored.



Cheers, Sergey



On Mon, Jan 11, 2016 at 5:17 AM, Sergey Beryozkin <sberyoz...@gmail.com>
wrote:

Hi Benson

The very first call into this method does not suspend the continuation,
so
there's no need to resume it if the exception is returned.
Do you see a mapped exception response not being returned ? Please
clarify

Cheers, Sergey


On 02/01/16 02:01, Benson Margulies wrote:

If I am in a method with an @Suspended AsyncResponse, and I neglect to
catch an exception, CXF runs mappers but they don't do any good, of
course, because nothing resumes the response.

How about if CXF instead logged at ERROR about any exception thrown
through a suspended resource method? I'm assuming that there's no way
to arrange for any uncaught exception to end up as
asyncResponse.resume(e).






--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Reply via email to