This PR is aiming to support one of the base pillars in a Kubernetes (or basically any cloud) enviroment; resiliency.
By default, all the savings happen manually by the user. If a container or the process itself goes down, there is no guarantee that the clients won't experience total loss of their progress. For the future, re-establishing connection to the client for a seamless QoS, this could also be helpful.
In this PR, at the creation of a room, just after the streaming starts, another goroutine would be called consisting timely saves with non-busy loop (thanks to @sergystepanov for that!), where the preiod of the saves could be configured from config.yaml in seconds (or completely disable with 0).
sergystepanov
commented
2 years ago
This PR is aiming to support one of the base pillars in a Kubernetes (or basically any cloud) enviroment; resiliency. By default, all the savings happen manually by the user. If a container or the process itself goes down, there is no guarantee that the clients won't experience total loss of their progress. For the future, re-establishing connection to the client for a seamless QoS, this could also be helpful.
In this PR, at the creation of a room, just after the streaming starts, another goroutine would be called consisting timely saves with non-busy loop (thanks to @sergystepanov for that!), where the preiod of the saves could be configured from
config.yamlin seconds (or completely disable with 0).