According to RFC 7231 status 503 means that the service is unavailable due to a temporary overload or scheduled maintenance, so it allows to retry later. While overload or maintenance may be causes for cancellation of a _request_, I doubt that these are the sole or even just predominant cause for cancelling a _ComputationStage_. So we should fall back on a safe vague position: 500 unexpected condition, which rather excatly matches that something exceptional -like an exception- happened.
-Markus
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
Sent: Dienstag, 25. April 2017 22:29
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: Returning CompletionStage from a resource method
AsyncResponse.cancel returns 503 with an optional Retry-After header
Canceling does not seem to qualify as a server error 500
Sergey
On 25/04/17 21:19, Markus KARG wrote:
> Throwing CancellationException sounds correct to me, and I think it would be a good idea to mandate that the fact of cancellation is mentioned in the error message when returning status 500.
>
> -Markus
>
> -----Original Message-----
> From: Pavel Bucek [mailto:pavel.bucek_at_oracle.com]
> Sent: Dienstag, 25. April 2017 09:56
> To: jsr370-experts_at_jax-rs-spec.java.net
> Subject: Returning CompletionStage from a resource method
>
> Dear experts,
>
> I was implementing support for returning CompletionStage from a resource method and I found some room for possible inconsistency:
>
> When returned CompletionStage is already done, we don't need to spawn another thread, we just use the same one. To be able to call "isDone", the implementation must convert CompletionStage to CompletableFuture (there is a method on the CompletionStage interface for that, so no issues so far).
>
> CompletableFuture has three terminal states:
>
> - completed,
> - completed exceptionally,
> - cancelled.
>
> When the state is completed, it is the same as when the resource method would return the type directly.
>
> When the state is completed exceptionally, it is the as when the resource method would thrown an exception.
>
> The question is what to do when the state is cancelled?
>
> My initial implementation throws IllegalStateException, but when looking to what is passed to CompletionStage.whenComplete, maybe the better way would be to throw CancellationException. (assuming that both, ISE or CE would be then processable by ExceptionMapper, if/when registered).
>
> Any ideas/opinions on which exception should be thrown?
>
> Thanks and regards,
> Pavel
>
>
> ps.: after seeing what I wrote, I convinced myself to use CancellationException - anyway, if anyone has other opinion, please share it.
>
>