[
https://issues.apache.org/jira/browse/HTTPCLIENT-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Uffmann updated HTTPCLIENT-2291:
-------------------------------------
Component/s: HttpClient (async)
HttpClient (classic)
Affects Version/s: 5.2
Description:
A RetryStrategy is enabled by default in both classic and async.
If an exec chain handler is placed *after* the retry handler, the behavior
between async and classic is consistent. The behavior of an Async- and a
classic ExecChainHandler placed *before* the (Async)HttpRequestRetryExec is
different when a retry is actually executed.
In case of a retry, the classic HttpRequestRetryExec will split the exec chain
and proceed with all handlers configured after itself. Any handler registered
before would be called exactly one time with the final outcome of the last
retry attempt.
The Async version, however, will call any handler registered before itself with
every retry. The order of events is counter intuitive as well. All closing
events will be emitted after the last attempt.
{*}Workaround{*}: In async, ignore all but the first invocation of a handler
when the handler is placed before the retry handler.
{*}Expected Bahaviour{*}: Both Async and Classic ExecChainHandler behavior
should be identical.
was:Async and
Summary: RetryStrategy: AsyncExecChainHandler and
ExecChainHandler behavior should be identical (was: RetryStrategy:
AsyncExecChainHandler and ExecChainHandler behavior should be equalized)
> RetryStrategy: AsyncExecChainHandler and ExecChainHandler behavior should be
> identical
> --------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-2291
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2291
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (async), HttpClient (classic)
> Affects Versions: 5.2
> Reporter: Lars Uffmann
> Priority: Major
>
> A RetryStrategy is enabled by default in both classic and async.
>
> If an exec chain handler is placed *after* the retry handler, the behavior
> between async and classic is consistent. The behavior of an Async- and a
> classic ExecChainHandler placed *before* the (Async)HttpRequestRetryExec is
> different when a retry is actually executed.
>
> In case of a retry, the classic HttpRequestRetryExec will split the exec
> chain and proceed with all handlers configured after itself. Any handler
> registered before would be called exactly one time with the final outcome of
> the last retry attempt.
>
> The Async version, however, will call any handler registered before itself
> with every retry. The order of events is counter intuitive as well. All
> closing events will be emitted after the last attempt.
>
> {*}Workaround{*}: In async, ignore all but the first invocation of a handler
> when the handler is placed before the retry handler.
>
> {*}Expected Bahaviour{*}: Both Async and Classic ExecChainHandler behavior
> should be identical.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
