Shinyproxy: Esclarecimento sobre a pulsação para contêineres docker

+1

Olá @ jat255

ShinyProxy atualmente funciona da seguinte maneira:

• cada proxy.heartbeat-rate ShinyProxy envia uma batida de coração para o cliente. Se o cliente atender, o estado interno será atualizado com a hora atual. O padrão de heartbeat-rate é 10 segundos. Essas pulsações são enviadas pelo canal do websocket (se houver).
• cada solicitação HTTP para um aplicativo também atualiza o estado interno.
• se o último batimento cardíaco de um contêiner for superior a proxy.heartbeat-timeout atrás, o ShinyProxy mata o aplicativo. Por padrão, 60 segundos.

Contanto que o usuário mantenha o navegador aberto e a conexão do websocket esteja aberta ou as solicitações HTTP sejam enviadas, o ShinyProxy presume que o aplicativo está em uso e, portanto, não o encerrará.
Observe que o Spring também manterá a sessão do usuário aberta enquanto o aplicativo estiver enviando solicitações HTTP.

Portanto, pode acontecer que os aplicativos estejam vivos por muito tempo. No entanto, vejo que você tem um aplicativo que fica aberto por 75 horas, o que significa cerca de três dias, isso significaria que o usuário fica com o computador funcionando por três dias (sem suspensão). Poderia ser este o caso? Caso contrário, você pode ter encontrado um bug, do qual não temos conhecimento.

BTW, temos alguns planos para um recurso max-lifetime , que mata o aplicativo após um determinado período de tempo, independentemente de estar em uso. Isso ainda não foi implementado e provavelmente não será feito na próxima versão. Vou mantê-lo informado se começarmos a trabalhar nisso.

@LEDfan muito obrigado pelo esclarecimento. Não tenho certeza se a sessão de longa duração é um bug ou se alguém deixou uma guia em execução no computador do escritório (tentando obter mais informações do usuário). Essa duração de sessão limitada é uma preocupação de segurança para nossa equipe de TI (eles não gostam de ver algo conectado por um longo tempo sem um usuário sentado lá). Algo como max-lifetime realmente seria útil. Acho que, entretanto, vamos criar uma função de tempo limite à la essa ideia , para apresentar aos nossos usuários um aviso de que eles estão prestes a ser desconectados e, em seguida, matar o servidor Shiny se não houver resposta, o que (pelo que entendi) deve fazer com que os contêineres do docker sejam limpos. Vou encerrar com base no esclarecimento acima. Obrigado!