Skip to content
This repository has been archived by the owner on May 5, 2023. It is now read-only.

Register HealthCheckServlet to admin port #135

Open
shharma-vipin opened this issue May 18, 2022 · 2 comments
Open

Register HealthCheckServlet to admin port #135

shharma-vipin opened this issue May 18, 2022 · 2 comments

Comments

@shharma-vipin
Copy link

shharma-vipin commented May 18, 2022

Hi Team, I recently noticed that HealthCheckServlet is added to application.
Assumption is anything related to state of application ( & not application itself) should be honoured at admin endpoints & not at application level.
This can be critical in the cases where application port is already heavily invoked & having health check there would put additional burden on application.
My ask is, can we register health check at admin port or at least provide way to configure it depending on user's input ?
Let me know if this sounds good & I can raise a PR.

@shharma-vipin
Copy link
Author

Screenshot 2022-05-18 at 22 09 13

Snippet from HealthCheckBundle that is registering servlet.

@pstackle
Copy link
Contributor

Hi @shharma-vipin

The HealthCheckServlet needs to be registered on the application context and not the admin context in order to fulfill its role of reporting on the health of the application, including whether the application is capable of responding to requests.

In Dropwizard, the application context and admin context are each configured with their own separate worker thread pools. If the servlet was registered on the admin context like you are suggesting, in a heavily congested/deadlocked application where there are no available worker threads, the application would no longer be able to process new requests but the servlet on the admin context would still be able to respond that the instance was healthy.

In that same scenario, but with the servlet on the application context instead, the servlet would be subject to the same congestion/deadlock and be unable to respond to a health check request. This lack of response serves as an implied unhealthy status which should ultimately result in the instance no longer receiving new requests.

In terms of performance, the health check responses should be extremely inexpensive as it is effectively just returning the response based on a boolean flag that is being updated in the background.

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

No branches or pull requests

2 participants