Markus, Sergey,
thanks for your comments and suggestions!
I do like consistency and I see CompletionStage as a special case of
AsyncResponse. In these circumstances, it makes sense to do what Sergey
suggests - return 503 (without a retry-after), since that's what happens
when AsyncResponse#cancel is invoked.
Best regards,
Pavel
On 25/04/2017 22:51, Sergey Beryozkin wrote:
> 503 without Retry-After...
> On 25/04/17 21:50, Sergey Beryozkin wrote:
>> 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.
>>>>
>>>>
>>>
>>
>