Comet, responseText e uso de memória

Question

Existe uma maneira de limpar o responseText de um objeto XHR sem destruir o objeto XHR?

Eu preciso manter um aberto conexão persistente com um servidor web para alimentar dados ao vivo para um navegador. O problema é que há uma quantidade relativamente grande de dados que chegam através de (K várias centenas por segundo constantemente), de modo que o uso de memória é um grande problema, porque esta conexão deve permanecer aberta durante pelo menos vários minutos. responseText fica muito grande muito rapidamente, mesmo que o JSON eu enviar de volta foi triturado tão pequeno quanto ele pode chegar.

Devido à forma como o aplicativo funciona em servidor lado, se eu usar AJAX-estilo curto de votação e apenas destruir o objeto XHR quando eu sou feito com ele, sinto falta de quantidades significativas de dados importantes, mesmo nos poucos milissegundos que leva para analisar a resposta, crie um novo XHR e enviá-lo para fora. Eu não tenho a opção de usar sobreposição de pedidos, como o servidor web só aceita uma conexão de cada vez. (Não pergunte). Então Comet é exatamente a necessidade modelo I.

O que eu gostaria de fazer é analisar cada pedaço JSON como ele vem de volta do servidor, e, em seguida, limpar responseText para que eu possa continuar usando a mesma conexão. No entanto, responseText é somente leitura. Ele não pode ser diretamente esvaziado por qualquer método que eu encontrei.

Existe uma parte da imagem que estou em falta aqui? Alguém sabe todos os truques que posso usar para liberar responseText quando eu terminar de lê-lo? Ou existe um outro lugar as respostas do servidor pode ir?

Eu não estou incluindo o código porque este é realmente quase uma questão de código-agnóstico. As rotinas JavaScript que geram os XHRs e lidar com os dados retornados são muito, muito simples.

Answer 1

É obras quão longo de votação. Você mantém um índice para o último número de linha de leitura e com cada instante de sua leitura intervalo a partir desse ponto em diante. É uma longa ligação, portanto, uma resposta longa.

A responseText fresco significaria uma conexão fresco. Mas então não seria cometa mais;)

Answer 2

Ao contrário da outra resposta, "long-polling" não é uma longa ligação. "Long-polling" é muitas conexões em seqüência, cada conjunto até Fique ligado para um período razoavelmente longo de tempo, se nenhuma resposta for necessário. Eles do tempo (normalmente em torno de 25-30s), e então re-estabelecer uma nova conexão. Desde HTTP1.1 permite a reutilização de conexões existentes, a conexão não tem que ser renegociado, e pode, portanto, ser praticamente instantaneamente restabelecida.

Assim, basta usar várias solicitações. Desde há realmente sobrecarga insignificante para re-estabelecer a conexão, e cada nova ligação irá permitir-lhe para destruir o texto de resposta anterior, esta é uma solução perfeitamente viável a partir de uma perspectiva de desempenho / sobrecarga, e iria resolver seus problemas de memória também.

[Edit] Eu estou falando da experiência, como um dos autores do WebSync .