[MAGNOLIA-9244] Align liveness & readiness with standard MicroProfile Health API Created: 15/Nov/23  Updated: 01/Feb/24  Resolved: 01/Feb/24

Status: Resolved
Project: Magnolia
Component/s: core
Affects Version/s: None
Fix Version/s: 6.3.0

Type: Task Priority: Neutral
Reporter: Mikaël Geljić Assignee: Antonín Juran
Resolution: Fixed Votes: 0
Labels: dx-core-6.3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MAGNOLIA-9245 Invert control between liveness/readi... Open
relates to MAGNOLIA-9247 Guice integration for auto-discovery ... Open
dependency
is depended upon by MGNLREST-781 Implement Health check rest endpoint Resolved
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Release notes required:
Yes
Documentation update required:
Yes
Epic Link: 6.3 Consolidation
Work Started:
Approved:
Yes

 Description   

First, we review vitals applicability to DX Core 6.3; the main cause for review is:

  • DX Core deployment is just the magnolia tomcat webapp
    • it doesn't have the vitals-webapp to consume vitals from.
    • it would be overhead for customers' to add in their own Dockerfiles, most likely they won't bother
  • also consuming over JMX is rather inconvenient → let's reconsider an embedded web facade?

Meanwhile, usage points are interesting:

  • MagnoliaServletContextListener: unlikely to remain useful, because if Magnolia is down, it's not gonna be able to respond
  • ModuleManagerImpl otoh is interesting, as a failed module start is a good readiness signal to stop accepting incoming requests

Therefore two main points for review:

  1. which API to use
  2. how to expose

API: do we still need the bespoke probes and similar, or can we reconsider MP Health?

  • MP Health would require a little Guice integration (no CDI), we have a bit of that today already too (see VitalsSupportModule)
  • we may not need probes to be auto-discoverable and instantiated by annotation, given our states evolve tightly within e.g. ModuleManager implementation
    • register and update HealthCheck probes in-place programmatically instead?

Endpoint:

  • after we validate the above, we should know better. e.g. could register a new endpoint instead of the former StatusEndpoint
  • implement /.rest/health/live and /.rest/health/ready and delegate to the underlying VitalsManager?
  • => MGNLREST ticket


 Comments   
Comment by Mikaël Geljić [ 11/Jan/24 ]

Initial review / confirmation of approach in description:

  • HealthCheckResponseProvider builder SPI (for curiosity)
  • build response more "volatile" within lambdas
  • check recommended aggregation point? (registry or endpoint) [MG, optional]
  • use Jakarta EE JSON-P instead of StringBuilder
  • failing tests - declare HCRegistry in MgnlTestCase & 
    ComponentProviderInitializer?
  • remove guice vitals package in core + dependency
  • clone to MGNLREST for the endpoint part

added follow-up tickets (not selected atm)

  • MAGNOLIA-9245 inversion of control between HealthCheck & ModuleManager
  • MAGNOLIA-9247 Guice integration for auto-discovery & injection within HealthChecks
Generated at Mon Feb 12 04:39:55 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.