I disagree, if the service code cancels it then this is what the service
implies, the service is unavailable to complete the request, and it
would be consistent (with AsyncResponse.cancel) to have 503 returned as
opposed to a code implying a server error has occurred and then starting
reinventing the wheel and indicating, as you suggested, that it was in
fact not a server error but a service-initiated cancellation.
Sergey
On 25/04/17 21:44, Markus KARG wrote:
> 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.
>>
>>
>