e1dc4b55e4
* fix(bbb-html5): customHeartbeat would not close stale sessions, + The [disabled by default] custom heartbeat included in Meteor's server does not end connections when they are considered unhealthy/stale, which deviates a bit from the default implementation. See: https://github.com/bigbluebutton/bigbluebutton/pull/11486. This commit includes a call to the default heartbeat termination timeout so sockets are correctly cleaned up when the custom heartbeat is activated. It also adds a customHeartbeatUseDataFrames config to allow controlling whether the custom heartbeat should use WS data frames as valid heartbeats as well - this should only be useful for testing/debugging purposes and the default behavior (true) is maintained. As a side note: this change spun off from an investigation where some problematic networks were triggering periodic client re-connects due to the default heartbeat failing. Investigation points to the control frames being put alongside fragmented WS data frames and the server side failing to recognize the former - which means pong frames would be missed and the health check would fail. Since the default heartbeat _does not_ account for data frame traffic (eg DDP payloads), it would shut down the client's WS even though it was healthy. The custom heartbeat _does_ account for data frames, which mitigates that scenario and prevents unecessary reconnections. * fix(bbb-html5): frontend crash due to undefined vars in customHeartbeat Meteor frontends may crash when customHeartbeat is enabled due to an undefined access in the heartbeat`s logger. Add optional chaining to the session props access so it won`t crash and tune down some log levels around that area. |
||
|---|---|---|
| .. | ||
| prom-metrics | ||
| ClientConnections.js | ||
| index.js | ||
| logger.js | ||
| metrics.js | ||
| minBrowserVersion.js | ||
| redis.js | ||
| settings.js | ||