Skip to content
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

Change to startup process to make health checking easier #133

Open
brownleej opened this issue Mar 27, 2019 · 1 comment · May be fixed by #218
Open

Change to startup process to make health checking easier #133

brownleej opened this issue Mar 27, 2019 · 1 comment · May be fixed by #218
Assignees
Milestone

Comments

@brownleej
Copy link
Member

Before the Document Layer binds to its listening address, it reads data from its backing FoundationDB cluster. This may present problems with health checking. Depending on how the organization's is using health checks, they may want to have health checks that succeed even if downstream dependencies are failing. For instance, if a FoundationDB database goes unavailable, the operators may not want the Document Layer instances to report as unhealthy, because that could cause a cascading series of failures. It may be preferable to have the Document Layer instances continue to receive traffic, so they can report more helpful error messages to their upstream clients.

Could we restructure this flow so that the Document Layer instances open their listening connection before reading from their FoundationDB cluster?

@apkar apkar modified the milestones: 1.6.4, 1.7.0, 1.8.0 Mar 27, 2019
@apkar apkar modified the milestones: 1.8.0, 2.0.0 Aug 12, 2019
@senthil-db-expert
Copy link

@apkar Please assign this ticket to me

senthil-db-expert added a commit to senthil-db-expert/fdb-document-layer that referenced this issue Sep 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants