See https://issues.apache.org/jira/browse/CXF-6744 and commit fa0eea884adf49a0a6f990e15a0e69d17800156e for my test case.
On Mon, Jan 11, 2016 at 7:03 AM, Sergey Beryozkin <[email protected]> wrote: > 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 <[email protected]> >> 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 <[email protected]> >>>> 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/
