-
Notifications
You must be signed in to change notification settings - Fork 22
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
fix(process worker): fix the crashing of pod #1119
fix(process worker): fix the crashing of pod #1119
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.
Please revert the changes in the framework dir since nothing changed in the framework logic
…calls. terminate processworker only when running out of memory. update framework version
c9ebf6f
to
b62273b
Compare
Quality Gate passedIssues Measures |
@dhiren-singh-007 @Phil91 : I think it makes sense to force a restart of the pod when it runs out of memory - everything else should be logged as critical. I also changed the way SocketException and IOException are handled within the remote api calls. Those wouln't throw this kind of systemexception but ServiceException flagged as RecoverOptions.NETWORK (being mapped to RecoverOptions.INFRASTRUCTURE which is most external system calls treat as recoverable skipping the process-step to be retried later). Nevertheless we might want to evaluate whether this is the right strategy for all external system calls - e.g. when calling a url that is provided by the customer it might be better to set the respective process-step to ERROR while retrying the same call with the next process-worker run would be suitable for calls to 'known as good' urls where it's reasonable to assume the network-related issue is temporary |
* terminate processworker only when running out of memory. * handle SocketException and IOException explicitly in external system calls. * update framework version * update process worker test --------- Co-authored-by: Norbert Truchsess <norbert.truchsess@t-online.de>
* terminate processworker only when running out of memory. * handle SocketException and IOException explicitly in external system calls. * update framework version * update process worker test --------- Co-authored-by: Norbert Truchsess <norbert.truchsess@t-online.de>
Description
Handled the system exception and added the Critical/Fatal log type so that we can monitor the logs for criticality.
Why
It was causing issues for other processes as well .
Eg if a OSP customer sets the wrong callback address or if it is down then it returns the referenced class of SystemException and then it crashed the pod , which stops all other processes.
Issue
#1114
Checklist
Please delete options that are not relevant.