Skip to content
This repository has been archived by the owner on Jan 30, 2020. It is now read-only.

Exit application if environment verification failed #75

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

welandaz
Copy link
Contributor

Description of the Change

This change performs exit from Java process if AbstractService.verifyEnvironment() throws an exception during application start up.

Benefits

Currently, if method throws an exception, process stays alive, even though application won't function properly. This change makes sure, that if application's environment isn't valid (or something went wrong while trying to verify it), the program will terminate with the proper error logged. (Before, even though the message was logged, application continued to work in a broken state and could potentially confuse monitoring systems)

Possible Drawbacks

None, unless the semantic of AbstractService.verifyEnvironment() isn't supposed to be treated like that and it's ok to fail and not terminate the application (or if someone has been using it like that already, in which case after this fix application won't start unless no exception is thrown)

@bkrahmer
Copy link
Contributor

bkrahmer commented Jul 16, 2018

I see the point of what you are suggesting. However, the design is as it is intentionally. In a k8s environment, if you start-up, realize your environment isn't complete and exit the process, it will just result in a non-stop series of service restarts. I'm not sure that is any better than a stalled container (with a critical health status).

@codec
Copy link
Contributor

codec commented Jul 17, 2018

👍 having this control in the service sounds good to me

@welandaz
Copy link
Contributor Author

@bkrahmer @codec Ok, I see the problem here, however there is already a process termination in case no OrangeMicroservice annotation was found (or service was ran with 'help' argument).

Doesn't that break the intent too? (k8s will try to start the app again)

@bkrahmer
Copy link
Contributor

Those are two cases not relevant to the real-world use cases. The first would be found by testing the service before deploying, and the second is just a mis-use.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants