Arquivamento programado não funciona quando existem muitos arquivos já arquivados.

[diogenesduarte]

Se existirem muitos arquivos arquivados em uma pasta local(de aproximadamente 4000 em diante), o arquivamento programado apresenta um erro e não arquiva mais mensagem nenhuma pois o parâmetro passado na URL com as mensagens que já foram arquivadas estoura a capacidade do GET. A solução seria adotar o metodo post no envio das requisições ajax para arquivamento local.

[diogenesduarte]

Replying to diogenesduarte:

Se existirem muitos arquivos arquivados em uma pasta local(de aproximadamente 4000 em diante), o arquivamento programado apresenta um erro e não arquiva mais mensagem nenhuma pois o parâmetro passado na URL com as mensagens que já foram arquivadas estoura a capacidade do GET. A solução seria adotar o metodo post no envio das requisições ajax para arquivamento local.

Ao falar muitos arquivos, quis me referir a muitas mensagens.

[diogenesduarte]

Pessoal, nos deparamos com um problema que talvez caiba discutir um pouco aqui se vocês concordam com o que fizemos para depois replicarmos no trunk. Alteramos a rotina para efetuar a chamada agora via post, como proposto no ticket, mas aconteceu que, como a funcionalidade de arquivamento local utiliza a todo momento chamadas ajax para buscar as mensagens que vai arquivar, ao chamar duas vezes a mesma URL via post, a segunda não era executada. Ao analisar, cheguei na parte que a requisição parava, no objeto connector. A linha problemática estava logo no começo do método newRequest e era a seguinte:

if (this.requests[id]) {
	return false;
}

Pelo que vi, esse id é a URL, e ela era adicionada nesse array request, e quando a URL era chamado mais de uma vez, simplesmente o método era encerrado retornando false. Não entendi muito o sentido disso, pois no mínimo ele teria que dar o retorno de algo vindo de um cache, mas notei que existia uma função de retorno, que era chamada logo após a conexão ajax retornar algo e essa função removia a posição this.requests[id]. O problema é que ele só remove isso após chamar o método de retorno de quem chamou connector, e nós encaramos que isso seria um erro, pois a ultima coisa na lógica da função que deveria ser chamada era justamente a chamada para a função de callback. Então, fizemos a seguinte alteração na função de retorno dentro do método newRequest:

era:

handler(data);
_thisObject.addToCache(params?id+"&"+params:id,data);
delete _thisObject.requests[id];								
_thisObject.requests[id] = null;

mudamos para:

_thisObject.addToCache(params?id+"&"+params:id,data);
delete _thisObject.requests[id];								
_thisObject.requests[id] = null;
handler(data);

Acredito que realmente essa chamada antes foi um erro, já fizemos testes e já colocamos essa modificação em ambiente de produção e até agora não tivemos nenhum problema, mas como é um objeto crítico e talvez a chamada ao handler antes de completar a lógica do método tenha tido algum motivo, resolvi pedir a opinião de vocês sobre isso antes de comitar.

[diogenesduarte]

Como não houve pronunciamentos, comitado na revisão [1857].