jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Re: resume(Throwable) question

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Wed, 6 Feb 2013 00:37:25 +0100

On Feb 5, 2013, at 8:59 PM, Bill Burke <bburke_at_redhat.com> wrote:

>
>
> On 2/5/2013 1:53 PM, Marek Potociar wrote:
>> I was under impression that leakage is implementation detail. We did not have to specify anything for sync case, why should we specify it for async case. There's nothing special about async case in this regard.
>>
>
> In he sync case, the Servlet container is wrapping the JAX-RS invocation. So, exceptions can be propagated and handled by the servlet container if need be. In the async case, a non-servlet thread is handling the response. So, cleanup, exception handling, etc. needs to either be handled by the jax-rs layer, or user code. IMO, cleanup and exception handling should be done in the JAX-RS layer and should be as deterministic.

Servlet is not the only platform JAX-RS runs on. Anyway, I think that propagating the exception to the IO container is deterministic enough. Whether or not this happens on the original thread is IMO orthogonal. All IO containers that support async externalise all the necessary connection-related context in one way or another and always provide a facility for propagating exceptions back to this context. I have yet to see a container that does not do that.

>
>> That said, I'm fine with adding a short sentence to the AR.resume()/cancel() javadoc stating that "A successful invocation of this method eventually completes the suspended request processing." or similar. FWIW, I do not want to write anything like "when this method completes, the request processing is complete", because I do not want to place restrictions on implementations. E.g. implementors may decide to complete the response processing asynchronously, which means that when the method returns the connection does not have to be necessarily closed yet. Which is also why I think it's better to not say anything...
>>
>
> Yeah, that's ok. If you want to force synchronicity, then you can just do it in the callback layer. It just wasn't very clear in the javadoc what was supposed to happen with unmapped exceptions. In the sync layer, the unmapped exception is rethrown. You just can't do that in the async layer, IMO.

Yes, that's the main difference. While in sync case the propagation is achieved by re-throwing and automatic rollback of the call stack, in async case this propagation needs to happen in some other way. Yet again, I have not seen any async-enabled IO container that would not expose such facility.

Marek

>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com