Shinyproxy: 澄清 docker 容器的心跳

+1

嗨@jat255

ShinyProxy 目前的工作方式如下：

• 每个proxy.heartbeat-rate ShinyProxy 都会向客户端发送一次心跳。 如果客户端应答，则内部状态用当前时间更新。 heartbeat-rate的默认值为 10 秒。 这些心跳通过 websocket 通道（如果有）发送。
• 对应用程序的每个 HTTP 请求也会更新内部状态。
• 如果容器的最后一次心跳比proxy.heartbeat-timeout之前长，ShinyProxy 会杀死应用程序。 这是默认的 60 秒。

只要用户保持浏览器打开并且 websocket 连接打开或发送 HTTP 请求，ShinyProxy 就会假设该应用程序正在使用中，因此不会终止它。
请注意，只要应用程序正在发送 HTTP 请求，Spring 也会保持用户会话处于打开状态。

因此，应用程序可能会存活很长时间。 但是，我看到您的应用程序打开了 75 小时，大约是三天，这意味着用户的计算机运行了三天（没有挂起）。 可能是这种情况吗？ 如果没有，您可能发现了一个我们不知道的错误。

顺便说一句，我们有一些max-lifetime功能的计划，它会在一定时间后杀死应用程序，无论它是否在使用中。 这尚未实现，可能不会在下一个版本中实现。 如果我们开始工作，我会通知你。

@LEDfan非常感谢您的澄清。 我不确定长时间运行的会话是否是一个错误，或者是否有人在他们的办公室计算机上运行了一个选项卡（试图从用户那里获取更多信息）。 这种有限的会话生命周期是我们 IT 安全团队的一个安全问题（他们不喜欢在没有用户坐在那里的情况下看到长时间登录的内容）。 像max-lifetime这样的东西确实很有用。 我认为，在此期间，我们将在超时功能烤一拉这个想法，一个警告，他们即将被注销，然后杀闪亮的服务器，如果没有响应，提出我们的用户，其（据我所知）应该让 docker 容器被清理干净。 我将根据上面的说明继续并关闭它。 谢谢！