-
Notifications
You must be signed in to change notification settings - Fork 61
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
Make PDS adapter steps resilient to network problems #2280
Comments
de-jcup
added a commit
that referenced
this issue
Jun 1, 2023
- changed unit tests to junit5 - adopted unit tests to work without spring
de-jcup
added a commit
that referenced
this issue
Jun 1, 2023
de-jcup
added a commit
that referenced
this issue
Jun 1, 2023
de-jcup
added a commit
that referenced
this issue
Jun 1, 2023
de-jcup
added a commit
that referenced
this issue
Jun 2, 2023
de-jcup
added a commit
that referenced
this issue
Jun 2, 2023
de-jcup
added a commit
that referenced
this issue
Jun 2, 2023
- ResilientActionExecutor infinite loop problem handled - renamed our FailableRunnable to RunOrFail, avoids name clashes with FailableRunnable from apache commons lang - added unit tests
de-jcup
added a commit
that referenced
this issue
Jun 2, 2023
- ResilientActionExecutor infinite loop problem handled - renamed our FailableRunnable to RunOrFail, avoids name clashes with FailableRunnable from apache commons lang - added unit tests - added missing SPDX headers
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Situation
After #2273 we are able to deploy continously new PDS versions. That works fine when we have K8s and use the continous deployment there.
But when we have only ONE instance for the PDS defined, and we directly kill the PDS process we have a downtime and there is no response to SecHub server while executing a SecHub job via PDS adapter:
The same when there would be any network connection problems.
Wanted
When there is temporary no communication available to PDS server, the PDS adapter call shall be resilient and retry the current step
Solution
Provide a resilience consultant for PDS adapter which is configurable (by executor configuration parameters) and has some nice defaults.
It shall be able handle per default 3 resource access exceptions and to wait 10 seconds before retry.
Details
Normally the resilience consultants are used by product executors, but it makes more sense to use them inside PDS adapter directly for every single step to avoid breaking the complete running PDS execution (and retry by
PDSResilienceConsultant
)For example: when the upload is not possible because of network problems, try it multiple times, if the job creation does not work, try it multiple times, if the job wait fails, try ONE wait multiple times before final exit...
Existing PDS resilience part in executor
After investigating and fixing #2281 there is the question if the PDS resilient consultant is really still helpful here or if the resilience logic shall all be done inside the adapter because of treating steps better.
PDSResilienceConsultant
does handleHttpClientErrorException
errors, means: There is at least connection available and those errors should normally not happen because of network problems.Because this another type of error, we keep
PDSResilienceConsultant
as is at the moment (maybe later we could move this error handling also into the adapter, but this is not part of this issue).The text was updated successfully, but these errors were encountered: