2012-09-04 18 views
5

Estoy usando SignalR en IE9 y, por desgracia, tiene que degradarse a usar la conexión de fotogramas para siempre.SignalR - Forever Frame en IE deja de funcionar después de unos minutos de estar inactivo

He pasado un tiempo mirando esto con las herramientas de desarrollo en IE. Puedo ver las devoluciones cargando en el IFrame insertado dinámicamente, y llaman a la función de recepción en el complemento SignalR. Sin embargo, después de aproximadamente 20/30 de estos simplemente deja de responder: ya no puedo llamar al script del cliente desde el servidor.

Supongo que la carga de IFrame finalmente se está agotando, pero parece que no hay eventos para esto, por lo que no puedo forzar la reconexión.

¿Alguien ha conseguido una conexión SignalR robusta trabajando en IE?

Gracias :)

+1

¿Qué versión de SignalR está usando? Solía ​​observar esto todo el tiempo en IE9 en versiones anteriores de SignalR, pero nunca más lo veo como 0.5. –

+1

También veo esto en IE9 con 0.5.3 en JabbR, tuve que cambiar a longPolling allí para hacerlo confiable. No fue capaz de descubrir exactamente qué está pasando todavía. –

+0

@DrewMarsh Estoy usando la última versión en NuGet - 0.5.3 – Kram

Respuesta

1

Cada vez que veía que esto ocurra, que en realidad tenía, procesos deshonestos zombie IE9 ejecutan en segundo plano. Ni siquiera tenían una ventana asociada a ellos. Entonces, iría y mataría a esos zombis y relanzaría una nueva instancia de IE y no tendría problemas por mucho tiempo hasta que la anamolía cause que el problema vuelva a ocurrir.

Lo siento, lo sé, pero pasé mucho tiempo explicando a David Fowler los síntomas del problema y cómo nunca podría ver ninguna razón para que el iFrame deje de disparar mágicamente el evento para que el transporte sepa que comenzará la próxima sesión iFrame. Los propios mensajes SignalR siempre terminaron correctamente el flujo de mensajes lógicos, el evento onreadystatechange simplemente dejaría de disparar.

+0

¿Por lo tanto, actualmente no hay una solución para este problema? además de acabar con viejas tareas ie9 en tu administrador de tareas? =/También tengo el mismo problema en Safari – anthonypliu

+0

El problema que estaba experimentando, no ... era algo con la forma en que el iframe funcionaba en IE que simplemente dejaba de disparar los eventos de cambio de estado listo de nuevo a la ventana principal hasta que maté el mal proceso de IE. –

8

Tuvimos un problema por el que el Javascript en un sitio web dejaba de funcionar, específicamente notamos esto porque las llamadas Ajax no funcionarían. Después de algunas investigaciones descubrimos que SignalR fue la razón del accidente, y encontramos esta publicación sobre Forever Frames. Hemos intentado quitar siempre los marcos de soporte en SignalR con el siguiente código JavaScript en el cliente:

$.connection.hub.start({ transport: ['webSockets', 'serverSentEvents', 'longPolling'] }); 

Así, sólo apoyo 'websockets', 'serverSentEvents', 'longPolling'.

+0

O puede establecer un tiempo de espera después de 1 a 2 minutos, por lo que el cliente debe volver a conectarse. –

+0

Crash? Qué significa bloqueo en este contexto – davidfowl

+0

Publicación editada para mayor precisión. Los bloqueos de JavaScipt: es decir, otras llamadas Ajax dejarían de funcionar (en concreto, una acción que devolvería una vista parcial en una llamada Ajax sería redireccionada a una página nueva). – Doff3n

1

De acuerdo con this problema de Github esto se corrigió en jQuery 1.10.1.

El problema se introdujo en 1.9.xy se corrigió en 1.10.1.

Corriendo con JQuery 1.8.1 parece que también funciona.

solución: Actualizar jQuery

0

Pon esto en caso listos documento y todos sus problemas se resolverían iframe:

$.connection.hub.start({ transport: ['webSockets', 'serverSentEvents', 'longPolling'] }); 
Cuestiones relacionadas