-
Notifications
You must be signed in to change notification settings - Fork 736
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
Retry all HttpException & SocketException in to methods (workaround http -1) #373
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approach sounds fine to me, especially if it has been demonstrated to work better than the original fix. Awaiting tuning of status code handling.
while (true) { | ||
try { | ||
return __to(tailApiUrl, type, instance); | ||
} catch (IOException e) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be limited to SocketTimeoutException
, as in the original?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, because HttpException
extends from IOException
.
I will limit the retry mechanism to only HttpException
s with status codes >= 400 && SocketException
-- I feel that there's merit to retrying other socket exceptions, such as connection reset errors.
This amends #359 FTR. |
I have just uploaded a snapshot of github-api-plugin with this branch to my jenkins instance and kicked off a full org scan. |
This implementation is not working as expected. We're still seeing -1 status HTTP responses in our logs periodically:
I will spend some time on this today or tomorrow. |
@borgstrom any progress? |
This is really causing problems at my organization. Any updates on this issue? Thanks. |
@borgstrom Progress? |
We have not had any problems in a long time. I consider this abandoned at this point. |
Could this pull request be reopened? The current retry mechanism does not have a delay and it fails when there are intermittent network issues. |
@bogdansuta-intel |
This PR is the result of needing to work around https://issues.jenkins-ci.org/browse/JENKINS-45142
We were seeing the following error quite frequently when scanning all repos in our github org:
The retry code in parse was not working as expected, so this moves the retry code directly into the
to
methods.