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.
>>>
>>>
>>
>