You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I propose a multi-part upgrade to the heartbeat feature with three main components:
Adding a special first heartbeat message
Adding a special last heartbeat message
Adding to the payload
The main purpose of this proposal is to make it easier to know what services are present on the mesh. This could enable interactions between services. It would also make it easier to implement a system for tracking what services exist on the mesh.
Current status
The heartbeat is a simple alert message sent at regular intervals from a service. The routing key starts with heartbeat.[service name]. The payload is the name and id of the service. Note that the heartbeat is currently not described in the standard, but there is an issue to address this absence (#39). The heartbeat is implemented in dl-cpp's heartbeater mixin class. The routing key prefix comes from core, and the use is in service::listen().
Proposed additions
First heartbeat message
The first heartbeat sent should announce the existence of a new service in the mesh. The routing key should be heartbeat.[service name].hello (or something to that effect).
Why
This will allow a service to learn of the existence of another service on the mesh. For example, service A might be able to use service B for something if the latter is present. Or there could be a service that keeps track of other services on the mesh.
Last heartbeat message
The heartbeater should make a best effort to send a last heartbeat message when it's shutting down. The routing key should be heartbeat.[service name].goodbye (or something to that effect).
Why
This would allow a service to learn that another service is leaving the mesh. If service A is using service B, it would want to know if service B leaves the mesh so it can configure itself appropriately. If a service is tracking what services exist on the mesh, this is the most efficient way to update the status of a service that leaves the mesh (the only other alternatives are to watch for a lack of heartbeats, or to constantly ping).
Payload additions
The following should be added to the payload:
heartbeat frequency
Why
This would allow a service that's keeping track of other services on the mesh to know when to worry about a lack of heartbeats from a service.
Implementation
The new functionality would be implemented in dl-cpp's heartbeater class. Specifically, it would all go in the execute() function. The new components of the routing keys for the hello and goodbye messages would go in core and be configurable.
The text was updated successfully, but these errors were encountered:
Introduction
I propose a multi-part upgrade to the heartbeat feature with three main components:
The main purpose of this proposal is to make it easier to know what services are present on the mesh. This could enable interactions between services. It would also make it easier to implement a system for tracking what services exist on the mesh.
Current status
The heartbeat is a simple alert message sent at regular intervals from a service. The routing key starts with
heartbeat.[service name]
. The payload is the name and id of the service. Note that the heartbeat is currently not described in the standard, but there is an issue to address this absence (#39). The heartbeat is implemented in dl-cpp'sheartbeater
mixin class. The routing key prefix comes fromcore
, and the use is inservice::listen()
.Proposed additions
First heartbeat message
The first heartbeat sent should announce the existence of a new service in the mesh. The routing key should be
heartbeat.[service name].hello
(or something to that effect).Why
This will allow a service to learn of the existence of another service on the mesh. For example, service A might be able to use service B for something if the latter is present. Or there could be a service that keeps track of other services on the mesh.
Last heartbeat message
The heartbeater should make a best effort to send a last heartbeat message when it's shutting down. The routing key should be
heartbeat.[service name].goodbye
(or something to that effect).Why
This would allow a service to learn that another service is leaving the mesh. If service A is using service B, it would want to know if service B leaves the mesh so it can configure itself appropriately. If a service is tracking what services exist on the mesh, this is the most efficient way to update the status of a service that leaves the mesh (the only other alternatives are to watch for a lack of heartbeats, or to constantly ping).
Payload additions
The following should be added to the payload:
Why
This would allow a service that's keeping track of other services on the mesh to know when to worry about a lack of heartbeats from a service.
Implementation
The new functionality would be implemented in dl-cpp's
heartbeater
class. Specifically, it would all go in theexecute()
function. The new components of the routing keys for thehello
andgoodbye
messages would go incore
and be configurable.The text was updated successfully, but these errors were encountered: