-
Notifications
You must be signed in to change notification settings - Fork 12
Health Monitoring interaction view #52
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,64 @@ | ||
| @startuml | ||
|
|
||
| box "User process" | ||
| participant "main" | ||
| participant "HealthMonitorBuilder" | ||
| participant "HealthMonitor" | ||
| participant "Lifecycle" | ||
| end box | ||
|
|
||
| box "LaunchDaemon process" | ||
| participant "LaunchDaemon" | ||
| end box | ||
|
|
||
| group APPLICATION_SELF_TERMINATING | ||
|
|
||
| ... | ||
|
|
||
| main -> main++: end_of_scope() | ||
| main -> HealthMonitor: destroy() | ||
| HealthMonitor -> LaunchDaemon: notify_stopped(timestamp) | ||
|
|
||
| ... | ||
|
|
||
| LaunchDaemon -> LaunchDaemon: stop_alive_monitoring() | ||
| main-- | ||
| end | ||
|
|
||
| group APPLICATION_TERMINATING_ON_LAUNCH_DAEMON_REQUEST | ||
|
|
||
| == LaunchDaemon Side == | ||
| ... | ||
|
|
||
| alt EXTERNAL_SHUTDOWN_REQUEST | ||
| LaunchDaemon -> LaunchDaemon: stop_alive_monitoring() | ||
| note left | ||
| Stop monitoring as now we monitor shutdown timeout | ||
| configured per app | ||
| end note | ||
|
|
||
| loop app in apps | ||
| LaunchDaemon -[#blue]> Lifecycle: notify_shutdown_request() | ||
| end | ||
| end alt | ||
|
|
||
| == Application Side == | ||
|
|
||
| LaunchDaemon -[#blue]> Lifecycle: notify_shutdown_request() | ||
| Lifecycle -> Lifecycle: release_main_for_shutdown() | ||
| ... | ||
|
|
||
| main -> main++: end_of_scope() | ||
| main -> HealthMonitor: destroy() | ||
| HealthMonitor -> LaunchDaemon: notify_stopped(timestamp) | ||
| note left | ||
| Notification is send to keep consistent with self terminating case | ||
| end note | ||
|
|
||
| HealthMonitor -> HealthMonitor: stop_background_thread() | ||
| HealthMonitor --> main | ||
|
|
||
| main-- | ||
| end | ||
|
|
||
| @enduml | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,87 @@ | ||
| @startuml | ||
|
|
||
| box "User process" | ||
| actor "user" | ||
| participant "HealthMonitorBuilder" | ||
| participant "HealthMonitor" | ||
| participant "Lifecycle" | ||
| end box | ||
|
|
||
| box "LaunchDaemon process" | ||
| participant "LaunchDaemon" | ||
| end box | ||
|
|
||
| == Application Side == | ||
| note right of user #lightblue | ||
| Each Application have **configuration** | ||
| for HealthMonitoring that is send to LaunchDaemon | ||
| end note | ||
|
|
||
| user -> HealthMonitorBuilder : build(supervisor_api_notification_cycle_time, ...) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would like to add to this diagram:
|
||
| HealthMonitorBuilder -> HealthMonitor: create | ||
| HealthMonitor -> LaunchDaemon: register_health_monitor(supervisor_api_notification_cycle_time, ...) | ||
| note left | ||
| All configuration needed can be send here | ||
| end note | ||
|
|
||
| HealthMonitorBuilder --> user: HealthMonitor instance | ||
|
|
||
| user -> HealthMonitor: start() | ||
| HealthMonitor -> LaunchDaemon: notify_started(timestamp) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. One point of discussion could be if we want to explicitly start the monitoring via a separate IPC call From the user point of view it could be viewed as redundant to have both as both say somewhat "I finished initialization". I am not sure which one is better, there seem to be advantages/disadvantages in both approaches. A related question would be: Do we want to support monitoring of applications that do not use the lifecycle api and do not report running state? The diagram currently assumes no.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Who is setting up the ipc channel and how?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is not yet in scope as we did not tackled usage of mw::com as API. So this we will add once we design MW:COM api after having first working version. |
||
| HealthMonitor -> HealthMonitor: start_background_thread() | ||
| note left | ||
| Notification has to finish before background thread starts | ||
| to not race with lifecycle api. | ||
| end note | ||
| ... | ||
|
|
||
| user -> Lifecycle: report_running() | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should show the case when the timeout of startup to running was crossed? |
||
| Lifecycle -> LaunchDaemon | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we should also depict when the monitoring stops during shutdown of the application. My assumption would be that:
Open question:
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
|
|
||
|
|
||
| == LaunchDaemon Side == | ||
|
|
||
| note left of LaunchDaemon #lightblue | ||
| Each application have **configuration entry** | ||
| for Lifecycle parameters (as part of LaunchDaemon config) like: | ||
| - self terminating or not | ||
| - health monitored | ||
| - timeouts for startup, shutdown, ... | ||
|
|
||
| This config **does not include** any Health Monitoring parameters | ||
| as those are send during HealthMonitor registration. | ||
| end note | ||
|
|
||
| ... | ||
| alt APPLICATION_USES_LIFECYCLE_API | ||
| user -> Lifecycle: report_running() | ||
| Lifecycle -> LaunchDaemon | ||
|
|
||
| LaunchDaemon -> LaunchDaemon: check_if_register_was_received() | ||
| note left #lightblue | ||
| This point is taken as **timestamp** used for | ||
| supervising application health monitoring. This point | ||
| is selected as before report_running we anyway monitoring | ||
| configured startup time per app and will handle errors in case | ||
| of timeout. | ||
| end note | ||
|
|
||
| alt not received | ||
| LaunchDaemon -> LaunchDaemon: error_reaction() | ||
| end | ||
|
|
||
| LaunchDaemon -> LaunchDaemon: check_if_notify_started_was_received() | ||
| alt not received | ||
| LaunchDaemon -> LaunchDaemon: error_reaction() | ||
| end | ||
|
|
||
|
|
||
| LaunchDaemon -> LaunchDaemon: start_monitor_user_application() | ||
| else APPLICATION_DOES NOT_USE_LIFECYCLE_API | ||
| note left of LaunchDaemon | ||
| **Health monitoring not allowed**, any register from this app | ||
| shall cause error reaction | ||
| end note | ||
| end | ||
|
|
||
| @enduml | ||
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.
We have to show the case when the notify_stopped was send but the app did not shutdown within the timeout?