¿Hay alguna forma de eliminar el texto de respuesta de un objeto XHR sin destruir el objeto XHR?Comet, responseText y uso de memoria
Necesito mantener una conexión permanente abierta a un servidor web para enviar datos en tiempo real a un navegador. El problema es que hay una cantidad relativamente grande de datos que llegan (varios cientos de K por segundo constantemente), por lo que el uso de la memoria es un gran problema, porque esta conexión debe permanecer abierta durante al menos varios minutos. responseText se pone muy grande muy rápido, a pesar de que el JSON que envío ha sido procesado lo más pequeño posible.
Debido a la forma en que funciona la aplicación del lado del servidor, si uso el sondeo corto al estilo AJAX y simplemente destruyo el objeto XHR cuando lo termino, echo de menos cantidades importantes de datos importantes incluso en los pocos milisegundos que toma analizar la respuesta, crear un nuevo XHR y enviarlo. No tengo la opción de usar solicitudes superpuestas, ya que el servidor web solo acepta una conexión a la vez. (No preguntes). Así que Comet es exactamente el modelo que necesito.
Lo que me gustaría hacer es analizar cada fragmento JSON a medida que vuelve del servidor, y luego borrar el texto de respuesta para poder seguir usando la misma conexión. Sin embargo, responseText es de solo lectura. No se puede vaciar directamente por ningún método que haya encontrado.
¿Hay una parte de la imagen que me falta aquí? ¿Alguien sabe algún truco que pueda usar para liberar texto de respuesta cuando termine de leerlo? ¿O hay otro lugar donde puedan ir las respuestas del servidor?
No incluyo el código porque esto es casi una cuestión de código independiente. Las rutinas Javascript que generan los XHR y manejan los datos devueltos son muy, muy simples.
Gracias. Yo entiendo el modelo. Solo esperaba que hubiera una forma de mantener la conexión sin tener que almacenar todo lo que se ha recibido en esa conexión en un gran buffer. Long-polling es un hack de todos modos, así que supongo que es mucho pedir que funcione exactamente como necesito :) – glomad
@ithcy: en realidad parece una solicitud razonable. Nunca lo había pensado mucho hasta que me lo preguntaste. Un 'xhr.flushResponseBuffer()' o algo así podría ser valioso para las conexiones de larga ejecución, y ahorraría tener que guardar una maldita referencia de número de línea todo el tiempo. –