Shinyproxy: Clarification sur le rythme cardiaque pour les conteneurs docker

+1

Salut @jat255

ShinyProxy fonctionne actuellement comme suit :

• chaque proxy.heartbeat-rate ShinyProxy envoie une pulsation au client. Si le client répond, l'état interne est mis à jour avec l'heure actuelle. La valeur par défaut de heartbeat-rate est de 10 secondes. Ces pulsations sont envoyées sur le canal Websocket (le cas échéant).
• chaque requête HTTP à une application met également à jour l'état interne.
• si le dernier battement d'écoute d'un conteneur est plus long qu'il y a proxy.heartbeat-timeout , ShinyProxy tue l'application. C'est par défaut 60 secondes.

Tant que l'utilisateur garde son navigateur ouvert et que la connexion Websocket est ouverte ou que des requêtes HTTP sont envoyées, ShinyProxy suppose que l'application est en cours d'utilisation et ne la tuera donc pas.
Notez que Spring gardera également la session de l'utilisateur ouverte tant que l'application envoie des requêtes HTTP.

Par conséquent, il peut arriver que les applications vivent longtemps. Cependant, je vois que vous avez une application ouverte pendant 75 heures, soit environ trois jours, cela signifierait que l'utilisateur a son ordinateur en marche pendant trois jours (sans suspension). Serait-ce le cas ? Sinon, vous avez peut-être trouvé un bogue dont nous ne sommes pas au courant.

BTW, nous avons des plans pour une fonctionnalité max-lifetime , qui tue l'application après un certain laps de temps, qu'elle soit ou non en cours d'utilisation. Ceci n'est pas encore implémenté et ne le sera probablement pas dans la prochaine version. Je vous tiendrai au courant si nous commençons à travailler dessus.

@LEDfan merci beaucoup pour la clarification. Je ne sais pas si la session de longue durée est un bogue ou si quelqu'un a laissé un onglet en cours d'exécution sur son ordinateur de bureau (en essayant d'obtenir plus d'informations de l'utilisateur). Cette durée de vie de session limitée est un problème de sécurité pour notre équipe de sécurité informatique (ils n'aiment pas voir quelque chose connecté pendant longtemps sans qu'un utilisateur soit assis là). Quelque chose comme max-lifetime serait en effet utile. Je pense que dans l'intervalle, nous allons faire cuire dans une fonction de délai d'attente à la cette idée , de présenter à nos utilisateurs un avertissement qu'ils sont sur le point d'être déconnecté, puis tuer le serveur Shiny s'il n'y a pas de réponse, qui (si je comprends bien) devrait faire nettoyer les conteneurs docker. Je vais aller de l'avant et clore ceci sur la base de la clarification ci-dessus. Merci!