0
238
VistasProblemas de SignalR y/o temporizador desde Chrome 88
Tenemos una aplicación ASP.Net WebForms que usa SignalR (v2.4.1) para realizar algunas comunicaciones bidireccionales entre el servidor y el cliente. Ha funcionado bien durante años: las conexiones son estables, cientos de usuarios lo usan, etc.
Sin embargo, comenzamos a recibir informes esporádicos de problemas de conexión de nuestra base de clientes, y todos informan lo mismo: si la sesión del navegador (Chrome) permanece inactiva durante más de 5 minutos, la conexión se interrumpe en segundo plano. Todos los temporizadores en la página dejan de ejecutarse regularmente, lo que (entre otras cosas) detiene el envío de "keepalives" y, finalmente, la conexión falla con el error del lado del cliente:
The client has been inactive since <date> and it has exceeded the inactivity timeout of 50000 ms. Stopping the connection.El procedimiento estándar después de esto sería reiniciar automáticamente la conexión, pero esto no hace nada. Si/cuando el usuario reactiva la página (por ejemplo, cambiando a la pestaña), todo comienza a volver a la vida, aunque con una conexión SignalR cerrada.
Después de mucha investigación, parece que estamos siendo afectados por este cambio introducido en Chrome v88, donde los temporizadores ( setTimeout s) están severamente restringidos si
- La página ha estado oculta por más de 5 minutos
- El temporizador se ha "encadenado" 5 o más veces; supongo que esto es similar a la recursividad, donde el temporizador se llama a sí mismo.
- La página ha estado "en silencio" durante 30 segundos
La condición de 5 minutos/30 segundos encaja con los informes que estamos recibiendo. Sin embargo, estamos ejecutando Javascript bastante básico en nuestra página: solo hay dos usos de setTimeout en nuestro propio código, ninguno de los cuales podría "encadenarse" (recurrir) a sí mismo. Tampoco podemos replicar el problema: nos sucedió en las pruebas, pero no podemos hacer que suceda de manera confiable. Deshabilitar esta función a través de chrome://flags/#intensive-wake-up-throttling parece mitigar el problema, pero, por supuesto, no podemos hacer que esto sea un requisito para usar nuestro sitio.
El único otro Javascript que se ejecuta en el sitio es jquery.signalR-2.4.1.js , y desde la fuente de SignalR, hay muchos setTimeout s allí. ¿Podría SignalR verse afectado por este cambio en Chrome? ¿Quizás cuando intenta volver a conectarse en silencio después de un problema de red temporal o algún otro evento impredecible?
Si no, ¿hay alguna forma, en cualquier navegador o IDE, de rastrear qué temporizadores se han iniciado (y, lo que es más importante, "encadenados"), para que podamos ver qué podría estar desencadenando esta restricción?
3 Respuestas
Responde la pregunta0
También estamos enfrentando problemas con nuestra señalR (WebSockets como transporte). No podemos reproducirlo en nuestro laboratorio. Los archivos HAR de nuestro cliente y el registro extendido nos proporcionaron solo la información de que el cliente "consume solo después de seguir grupos interesantes" no envía pings dentro de los 30 segundos predeterminados necesarios para mantener la conexión. Por lo tanto, el servidor cierra la conexión. Agregamos registros en la biblioteca del cliente de signalR y solo vimos que el temporizador de ping no se alcanzó a tiempo. Sin error, sin nada. (El cliente es JavaScript y el problema ocurrió en el sitio del cliente en Chrome 87 (la limitación ya se implementó allí para la mitad de los usuarios de Chrome: https://support.google.com/chrome/a/answer/7679408#87 ))
Y el mundo se está dando cuenta lentamente de "un problema": https://github.com/SignalR/SignalR/issues/4536
Nuestra ayuda rápida para nuestros clientes será crear un ET con un mecanismo de ping-pong de transmisión manual desde el sitio del servidor y cada cliente tendrá que responder. Evitar depender del ping de JavaScript en la biblioteca de signalR hasta que se proporcione una solución o arreglo "mejor".
0
Sé que no resuelve el problema por completo con Chrome, sin embargo, el nuevo borde que usa el motor Chrome ha agregado algunas configuraciones nuevas para controlar los tiempos de espera (ya que también se vio afectado por el cambio). Hay una nueva opción de lista blanca que otorga al menos el poder a los usuarios para decidir qué páginas se excluyen de este comportamiento. Honestamente, creo que Google agregará esta configuración tarde o temprano. Hasta entonces, recomendamos a nuestros clientes que cambien a Edge si se ven afectados.
Puede encontrarlo en configuración\sistema: 