New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CAMEL-18582: Remove SocketTimeoutException from non retryable classes #8497
Conversation
🚫 There are (likely) no components to be tested in this PR |
3 similar comments
🚫 There are (likely) no components to be tested in this PR |
🚫 There are (likely) no components to be tested in this PR |
🚫 There are (likely) no components to be tested in this PR |
🚫 There are (likely) no components to be tested in this PR |
3 similar comments
🚫 There are (likely) no components to be tested in this PR |
🚫 There are (likely) no components to be tested in this PR |
🚫 There are (likely) no components to be tested in this PR |
During the last build, we can see in the log file that several |
…apache#8497) ## Motivation With the latest fix, we now get errors of type `SocketTimeoutException: Read timed out` indicating that the runner loses regularly the connection with maven central for some period of time but as it can recover it, to workaround it, we need to make sure that it can retry when it faces this kind of error. ## Modifications: * Use `default` as retry handler instead of `standard` to be able to change the non-retryable classes * By default, `SocketTimeoutException` as a subclass of `InterruptedIOException` is part of the non-retryable classes which is the reason why no retries are made, so we need to redefine the non-retryable classes without `InterruptedIOException` to make sure that it will retry in case of `Read timed out`
Related to https://issues.apache.org/jira/browse/CAMEL-18582
Motivation
With the latest fix, we now get errors of type
SocketTimeoutException: Read timed out
indicating that the runner loses regularly the connection with maven central for some period of time but as it can recover it, to workaround it, we need to make sure that it can retry when it faces this kind of error.Modifications:
default
as retry handler instead ofstandard
to be able to change the non-retryable classesSocketTimeoutException
as a subclass ofInterruptedIOException
is part of the non-retryable classes which is the reason why no retries are made, so we need to redefine the non-retryable classes withoutInterruptedIOException
to make sure that it will retry in case ofRead timed out