You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Joshua Spiewak <js...@gmail.com> on 2012/06/08 16:32:29 UTC
extensibility of DefaultHttpRequestRetryHandler
The HttpClient tutorial uses socket timeout as an example of a recoverable
error in the introduction to Section 1.3 Exception Handling. However,
the DefaultHttpRequestRetryHandler will *not* retry when there is an
InterruptedIOException, e.g. a socket timeout. Could someone share the
reasoning behind not retrying in this case? What is an example of a
sub-class of IOException that would be handled by
the DefaultHttpRequestRetryHandler? From looking at
TestDefaultHttpRequestRetryHandler, the only test case that expects a retry
is retryOnNonAbortedRequests, which use a straight IOException as the
exception to handle. There is no test case for SocketTimeoutException.
I have internal applications that may experience a SocketTimeoutException
when there is a surge of requests, and in these circumstances I would like
to retry. I'd prefer not to copy the entire DefaultHttpRequestRetryHandler
class in order to allow for retries in this case.
Would it make sense to have a Set<Class<IOException>>, by default
containing the enumerated exceptions, but is exposed to sub-classes that
can then add or remove entries?
Or is there a better way of making DefaultHttpRequestRetryHandler
extensible?
Thanks!
-- Josh
Re: extensibility of DefaultHttpRequestRetryHandler
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2012-06-11 at 13:20 -0400, Joshua Spiewak wrote:
> On Mon, Jun 11, 2012 at 11:28 AM, Oleg Kalnichevski <ol...@apache.org>wrote:
>
> > On Mon, 2012-06-11 at 10:12 -0400, Joshua Spiewak wrote:
> > > What about the scenario where a service is behind a load balancer?
> > > In this case, one of two instances of the service is slow, and the load
> > > balancer takes it out of service. A second request is required in order
> > to
> > > succeed, as opposed to just waiting twice as long.
> > >
> > > I am not sure I understand your second paragraph. Are you saying that
> > since
> > > STE is a subclass of IOE, that you think an idempotent requests _should_
> > be
> > > retried, or _should not_ be retried?
> > >
> >
> > Excuse my being such a mess. Yes, I meant to say SocketExceptions were
> > expected to be retried automatically provided other conditions (such as
> > request idempotency) were satisfied.
> >
> >
> No problem. But back to my original point, SocketTimeoutException extends
> InterruptedIOException, and that is explicitly not retried. So is that a
> bug?
>
>
No, this is intended. InterruptedIOException are not automatically
re-tried per default.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: extensibility of DefaultHttpRequestRetryHandler
Posted by Joshua Spiewak <js...@gmail.com>.
On Mon, Jun 11, 2012 at 11:28 AM, Oleg Kalnichevski <ol...@apache.org>wrote:
> On Mon, 2012-06-11 at 10:12 -0400, Joshua Spiewak wrote:
> > What about the scenario where a service is behind a load balancer?
> > In this case, one of two instances of the service is slow, and the load
> > balancer takes it out of service. A second request is required in order
> to
> > succeed, as opposed to just waiting twice as long.
> >
> > I am not sure I understand your second paragraph. Are you saying that
> since
> > STE is a subclass of IOE, that you think an idempotent requests _should_
> be
> > retried, or _should not_ be retried?
> >
>
> Excuse my being such a mess. Yes, I meant to say SocketExceptions were
> expected to be retried automatically provided other conditions (such as
> request idempotency) were satisfied.
>
>
No problem. But back to my original point, SocketTimeoutException extends
InterruptedIOException, and that is explicitly not retried. So is that a
bug?
> > Given the current pattern of the code, having a set of classes
> representing
> > non-retry-able exceptions was what I was proposing, as opposed to the
> > positive case of a set of retry-able exceptions. What is the best way to
> > contribute a patch?
> >
>
> By raising an enhancement request in JIRA and attaching the patch to it.
>
>
I will see if I can find some time this week.
Thanks!
-- Josh
> On Sat, Jun 9, 2012 at 7:01 AM, Oleg Kalnichevski <ol...@apache.org>
> wrote:
> >
> > > On Fri, 2012-06-08 at 10:32 -0400, Joshua Spiewak wrote:
> > > > The HttpClient tutorial uses socket timeout as an example of a
> > > recoverable
> > > > error in the introduction to Section 1.3 Exception Handling. However,
> > > > the DefaultHttpRequestRetryHandler will *not* retry when there is an
> > > > InterruptedIOException, e.g. a socket timeout. Could someone share
> the
> > > > reasoning behind not retrying in this case? What is an example of a
> > > > sub-class of IOException that would be handled by
> > > > the DefaultHttpRequestRetryHandler? From looking at
> > > > TestDefaultHttpRequestRetryHandler, the only test case that expects a
> > > retry
> > > > is retryOnNonAbortedRequests, which use a straight IOException as the
> > > > exception to handle. There is no test case for
> SocketTimeoutException.
> > > >
> > > > I have internal applications that may experience a
> SocketTimeoutException
> > > > when there is a surge of requests, and in these circumstances I would
> > > like
> > > > to retry. I'd prefer not to copy the entire
> > > DefaultHttpRequestRetryHandler
> > > > class in order to allow for retries in this case.
> > > >
> > > > Would it make sense to have a Set<Class<IOException>>, by default
> > > > containing the enumerated exceptions, but is exposed to sub-classes
> that
> > > > can then add or remove entries?
> > > >
> > > > Or is there a better way of making DefaultHttpRequestRetryHandler
> > > > extensible?
> > > >
> > > > Thanks!
> > > >
> > > > -- Josh
> > >
> > > Hi Josh
> > >
> > > It seems odd to me that one would want to retry requests on connect or
> > > socket timeouts N times effectively making timeout value N * T instead
> > > of T. One might as well set a higher timeout value from the beginning.
> > >
> > > SocketTimeoutException is a subclass of IOException, and I see no
> reason
> > > why it should be retried automatically by the
> > > DefaultHttpRequestRetryHandler as long as the request that caused it is
> > > idempotent.
> > >
> > > Having a set of classes that represent a recoverable condition sounds
> > > like a good idea to me. Please do feel free to contribute a better
> > > implementation of DefaultHttpRequestRetryHandler.
> > >
> > > Oleg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > >
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
Re: extensibility of DefaultHttpRequestRetryHandler
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2012-06-11 at 10:12 -0400, Joshua Spiewak wrote:
> What about the scenario where a service is behind a load balancer?
> In this case, one of two instances of the service is slow, and the load
> balancer takes it out of service. A second request is required in order to
> succeed, as opposed to just waiting twice as long.
>
> I am not sure I understand your second paragraph. Are you saying that since
> STE is a subclass of IOE, that you think an idempotent requests _should_ be
> retried, or _should not_ be retried?
>
Excuse my being such a mess. Yes, I meant to say SocketExceptions were
expected to be retried automatically provided other conditions (such as
request idempotency) were satisfied.
> Given the current pattern of the code, having a set of classes representing
> non-retry-able exceptions was what I was proposing, as opposed to the
> positive case of a set of retry-able exceptions. What is the best way to
> contribute a patch?
>
By raising an enhancement request in JIRA and attaching the patch to it.
Oleg
> Thanks,
>
> -- Josh
>
>
> On Sat, Jun 9, 2012 at 7:01 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> > On Fri, 2012-06-08 at 10:32 -0400, Joshua Spiewak wrote:
> > > The HttpClient tutorial uses socket timeout as an example of a
> > recoverable
> > > error in the introduction to Section 1.3 Exception Handling. However,
> > > the DefaultHttpRequestRetryHandler will *not* retry when there is an
> > > InterruptedIOException, e.g. a socket timeout. Could someone share the
> > > reasoning behind not retrying in this case? What is an example of a
> > > sub-class of IOException that would be handled by
> > > the DefaultHttpRequestRetryHandler? From looking at
> > > TestDefaultHttpRequestRetryHandler, the only test case that expects a
> > retry
> > > is retryOnNonAbortedRequests, which use a straight IOException as the
> > > exception to handle. There is no test case for SocketTimeoutException.
> > >
> > > I have internal applications that may experience a SocketTimeoutException
> > > when there is a surge of requests, and in these circumstances I would
> > like
> > > to retry. I'd prefer not to copy the entire
> > DefaultHttpRequestRetryHandler
> > > class in order to allow for retries in this case.
> > >
> > > Would it make sense to have a Set<Class<IOException>>, by default
> > > containing the enumerated exceptions, but is exposed to sub-classes that
> > > can then add or remove entries?
> > >
> > > Or is there a better way of making DefaultHttpRequestRetryHandler
> > > extensible?
> > >
> > > Thanks!
> > >
> > > -- Josh
> >
> > Hi Josh
> >
> > It seems odd to me that one would want to retry requests on connect or
> > socket timeouts N times effectively making timeout value N * T instead
> > of T. One might as well set a higher timeout value from the beginning.
> >
> > SocketTimeoutException is a subclass of IOException, and I see no reason
> > why it should be retried automatically by the
> > DefaultHttpRequestRetryHandler as long as the request that caused it is
> > idempotent.
> >
> > Having a set of classes that represent a recoverable condition sounds
> > like a good idea to me. Please do feel free to contribute a better
> > implementation of DefaultHttpRequestRetryHandler.
> >
> > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: extensibility of DefaultHttpRequestRetryHandler
Posted by Joshua Spiewak <js...@gmail.com>.
What about the scenario where a service is behind a load balancer?
In this case, one of two instances of the service is slow, and the load
balancer takes it out of service. A second request is required in order to
succeed, as opposed to just waiting twice as long.
I am not sure I understand your second paragraph. Are you saying that since
STE is a subclass of IOE, that you think an idempotent requests _should_ be
retried, or _should not_ be retried?
Given the current pattern of the code, having a set of classes representing
non-retry-able exceptions was what I was proposing, as opposed to the
positive case of a set of retry-able exceptions. What is the best way to
contribute a patch?
Thanks,
-- Josh
On Sat, Jun 9, 2012 at 7:01 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Fri, 2012-06-08 at 10:32 -0400, Joshua Spiewak wrote:
> > The HttpClient tutorial uses socket timeout as an example of a
> recoverable
> > error in the introduction to Section 1.3 Exception Handling. However,
> > the DefaultHttpRequestRetryHandler will *not* retry when there is an
> > InterruptedIOException, e.g. a socket timeout. Could someone share the
> > reasoning behind not retrying in this case? What is an example of a
> > sub-class of IOException that would be handled by
> > the DefaultHttpRequestRetryHandler? From looking at
> > TestDefaultHttpRequestRetryHandler, the only test case that expects a
> retry
> > is retryOnNonAbortedRequests, which use a straight IOException as the
> > exception to handle. There is no test case for SocketTimeoutException.
> >
> > I have internal applications that may experience a SocketTimeoutException
> > when there is a surge of requests, and in these circumstances I would
> like
> > to retry. I'd prefer not to copy the entire
> DefaultHttpRequestRetryHandler
> > class in order to allow for retries in this case.
> >
> > Would it make sense to have a Set<Class<IOException>>, by default
> > containing the enumerated exceptions, but is exposed to sub-classes that
> > can then add or remove entries?
> >
> > Or is there a better way of making DefaultHttpRequestRetryHandler
> > extensible?
> >
> > Thanks!
> >
> > -- Josh
>
> Hi Josh
>
> It seems odd to me that one would want to retry requests on connect or
> socket timeouts N times effectively making timeout value N * T instead
> of T. One might as well set a higher timeout value from the beginning.
>
> SocketTimeoutException is a subclass of IOException, and I see no reason
> why it should be retried automatically by the
> DefaultHttpRequestRetryHandler as long as the request that caused it is
> idempotent.
>
> Having a set of classes that represent a recoverable condition sounds
> like a good idea to me. Please do feel free to contribute a better
> implementation of DefaultHttpRequestRetryHandler.
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
Re: extensibility of DefaultHttpRequestRetryHandler
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2012-06-08 at 10:32 -0400, Joshua Spiewak wrote:
> The HttpClient tutorial uses socket timeout as an example of a recoverable
> error in the introduction to Section 1.3 Exception Handling. However,
> the DefaultHttpRequestRetryHandler will *not* retry when there is an
> InterruptedIOException, e.g. a socket timeout. Could someone share the
> reasoning behind not retrying in this case? What is an example of a
> sub-class of IOException that would be handled by
> the DefaultHttpRequestRetryHandler? From looking at
> TestDefaultHttpRequestRetryHandler, the only test case that expects a retry
> is retryOnNonAbortedRequests, which use a straight IOException as the
> exception to handle. There is no test case for SocketTimeoutException.
>
> I have internal applications that may experience a SocketTimeoutException
> when there is a surge of requests, and in these circumstances I would like
> to retry. I'd prefer not to copy the entire DefaultHttpRequestRetryHandler
> class in order to allow for retries in this case.
>
> Would it make sense to have a Set<Class<IOException>>, by default
> containing the enumerated exceptions, but is exposed to sub-classes that
> can then add or remove entries?
>
> Or is there a better way of making DefaultHttpRequestRetryHandler
> extensible?
>
> Thanks!
>
> -- Josh
Hi Josh
It seems odd to me that one would want to retry requests on connect or
socket timeouts N times effectively making timeout value N * T instead
of T. One might as well set a higher timeout value from the beginning.
SocketTimeoutException is a subclass of IOException, and I see no reason
why it should be retried automatically by the
DefaultHttpRequestRetryHandler as long as the request that caused it is
idempotent.
Having a set of classes that represent a recoverable condition sounds
like a good idea to me. Please do feel free to contribute a better
implementation of DefaultHttpRequestRetryHandler.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org