Cometa, responseText y uso de la memoria

Question

¿Hay una manera de limpiar el responseText de un objeto XHR sin destruir el objeto XHR?

Necesito mantener una conexión persistente a un servidor web para alimentar datos en tiempo real a un navegador. El problema es que hay una cantidad relativamente grande de datos que llegan a través de (varios cientos de K por segundo en constante), por lo que el uso de memoria es un gran problema, porque esta conexión debe permanecer abierta durante al menos varios minutos. responseText se pone muy grande muy rápidamente, a pesar de que el JSON envío de vuelta se ha crujía tan pequeño como se puede conseguir.

Debido a la forma en que funciona la aplicación del lado del servidor, si uso de estilo AJAX corta de votación y simplemente destruir el objeto XHR cuando he terminado con ella, me olvido de cantidades significativas de datos importantes incluso en los pocos milisegundos que toma para analizar la respuesta, crear un nuevo XHR y enviarlo a cabo. Yo no tengo la opción de utilizar las solicitudes superpuestas, como el servidor web sólo acepta una conexión a la vez. (No pregunte.) Así que el cometa es exactamente el modelo que necesito.

Lo que me gustaría hacer es analizar cada fragmento JSON, ya que viene de vuelta desde el servidor, y luego a despejar responseText para que pueda seguir usando la misma conexión. Sin embargo, responseText es de sólo lectura. No se puede vaciar directamente por cualquier método que he encontrado.

¿Hay una parte de la imagen que estoy perdiendo aquí? ¿Alguien sabe algún truco que puedo usar para liberar responseText cuando he terminado de leerlo? ¿O hay otro lugar las respuestas del servidor pueden ir?

No estoy incluyendo código, porque esto es realmente casi una pregunta código agnóstica. Las rutinas de Javascript que se reproducen las XHR y manejan los datos devueltos son muy, muy simple.

Answer 1

Así es como funciona largo de votación. A mantener un índice en el último número de la línea de lectura y con cada tic de su intervalo de lectura a partir de ese punto en adelante. Es una conexión de largo, por lo tanto una respuesta a largo.

A responseText fresca significaría una conexión nueva. Pero entonces no sería el cometa más;)

Answer 2

A diferencia de la otra respuesta, "a largo sondeo" no es una conexión de largo. "Long-polling" es muchas conexiones en secuencia, cada uno configurado para permanecer conectado durante un período razonablemente largo de tiempo si es necesaria ninguna respuesta. Ellos hacer intervalo de tiempo (típicamente alrededor de 25-30s), y luego volver a establecer una nueva conexión. Desde HTTP1.1 permite la reutilización de las conexiones existentes, la conexión no tiene que ser re-negociado, y puede por lo tanto ser restablecida prácticamente al instante.

Por lo tanto, sólo tiene que utilizar múltiples peticiones. Puesto que realmente hay sobrecarga despreciable para restablecer la conexión, y cada nueva conexión le permitirá destruir el texto de la respuesta anterior, esta es una solución perfectamente viable desde una perspectiva de rendimiento / gastos generales, y resolvería sus problemas de memoria también.

[Editar] Estoy hablando de la experiencia, como uno de los autores de WebSync .