Erro ao consultar protocolo

[jcmferreira]

Boa tarde pessoal!

Estou com um problema estranho, ocorre de forma aleatória e que ainda não consegui identificar. Em muitos dos nossos clientes, quando tentamos consultar o protocolo com o método Consultar, seguindo rigidamente o padrão implementado pelo projeto ACBr eSocial.

ERRO: WebService Consulta Status serviço:
- Inativo ou Inoperante tente novamente.
Erro Interno: 10060
Erro HTTP: 0

Alguém tem ideia do que seja isso? Meus fontes já estão no Trunk2.

 

Agradeço antecipadamente pela ajuda!

[Alisson Souza Pereira]

Sabe dizer a frequencia com que isso corre? 
É normal esse tipo de time out, porém não frequentemente. 
Basta consultar novamente que dará certo. 
A única observação sobre isso é se vc estiver sobrecarregando o servidor de consulta com consultas desnecessárias, o eSocial já informou nos manuais 
que se a aplicação ficar consultando indevidamente um lote que ainda não foi processando ele vai limitar o acesso e poderia ocorrer um time out. 
Normalmente 1 min é o suficiente para o eSocial processar o evento (Tem exceções como o S-1299) @jcmferreira

Editado 8 Agosto, 2018 por Alisson Souza Pereira

[jcmferreira]

16 horas atrás, Alisson Souza Pereira disse:

Sabe dizer a frequencia com que isso corre? 
É normal esse tipo de time out, porém não frequentemente. 
Basta consultar novamente que dará certo. 
A única observação sobre isso é se vc estiver sobrecarregando o servidor de consulta com consultas desnecessárias, o eSocial já informou nos manuais 
que se a aplicação ficar consultando indevidamente um lote que ainda não foi processando ele vai limitar o acesso e poderia ocorrer um time out. 
Normalmente 1 min é o suficiente para o eSocial processar o evento (Tem exceções como o S-1299) @jcmferreira

Alisson, valeu pela preocupação!

Esse "erro" (caso confirmado o timeout mencionado por você) está ficando com uma frequência relativamente chata agora. Passou a gerar incomodo em alguns casos.

Nossa solução está da seguinte forma:

1. Enviamos um lote (nunca em paralelo)
2. Dependendo do retorno (caso resposta positiva e exista o protocolo), realizamos a primeira consulta (aqui, o tempo não chega em 1 minuto... é na sequencia mesmo)
3. Caso haja 101, tentamos ver se a tag de tempo estimado veio (nunca vi na vida, pra ser sincero). Caso negativo, damos um intervalo de 3 minutos para a próxima consulta.
4. Fica no "loop" repetindo os passos acima até finalizar todos os lotes que precisam ser enviados, de todos os eventos.

Talvez, o problema esteja na consulta imediatamente após o envio do lote, não? Mas confesso que se sim, começou faz coisa de um mês apenas.

[Alisson Souza Pereira]

Verifiquei por cima os meus eventos 10.000 eventos 5 time outs.

No meu caso estou trabalhando com thread, excetuando os evento de tabela é possível enviar vários eventos e ir consultando de forma gradativa, e como a conexão é assincrona
não tem porque vc enviar esperar a consulta deste evento para poder enviar o próximo, basta criar uma regra de encadeamento para os eventos que possuem dependencia respeitarem a sua ordem. 

No meu caso pouco importa quantos time out dê, me parece que são servidores distintos(esocial envio / esocial consulta), as consultas estão dando time out mas o envio continua funcionando, quando o servidor de consulta 
volta a funcionar, as consultas passam a ser realizadas normalmente e os lotes que deram time out serão consultados de forma AUTOMÁTICA...

no seu caso quando dá time out vc tem que intervir??
Não consegui entender qual está sendo o seu problema, porque mesmo que dê o time out a própria mensageria sabe que quando o eSocial voltar a funcionar este evento deverá ser consultado. 

[jcmferreira]

1 hora atrás, Alisson Souza Pereira disse:

Verifiquei por cima os meus eventos 10.000 eventos 5 time outs.

No meu caso estou trabalhando com thread, excetuando os evento de tabela é possível enviar vários eventos e ir consultando de forma gradativa, e como a conexão é assincrona
não tem porque vc enviar esperar a consulta deste evento para poder enviar o próximo, basta criar uma regra de encadeamento para os eventos que possuem dependencia respeitarem a sua ordem. 

No meu caso pouco importa quantos time out dê, me parece que são servidores distintos(esocial envio / esocial consulta), as consultas estão dando time out mas o envio continua funcionando, quando o servidor de consulta 
volta a funcionar, as consultas passam a ser realizadas normalmente e os lotes que deram time out serão consultados de forma AUTOMÁTICA...

no seu caso quando dá time out vc tem que intervir??
Não consegui entender qual está sendo o seu problema, porque mesmo que dê o time out a própria mensageria sabe que quando o eSocial voltar a funcionar este evento deverá ser consultado. 

Alisson,

Na verdade, apenas queria entender o contexto do erro. Uma forma de resolver isso transparente, sem precisar aprofundar muito na lógica. Mas já que vc entrou nesse assunto, o nosso sistema, na prática, é um web service próprio (desenvolvido por nós mesmos) que fornece uma série de APIs rodando pesadamente em multi-thread e totalmente assíncrono. O RH3 Smart é o produto responsável por todo esse gerenciamento do eSocial dentro do ambiente dos clientes. Tudo de forma transparente e sem interferência do usuário em quase 90% dos casos (salvando-se os eventos que são requisitados para auditoria pré-envio).

A descrição feita foi um pequeno trecho do processo de envio de lote e sequencial consulta do protocolo. Mas isso, de forma macro, está ocorrendo em paralelo com outros lotes e consultas, sempre respeitando as regras impostas pelo eSocial. Alguns de nossos clientes na fase de adesão, chegaram a enviar mais de 100.000 eventos em mais de 2.000 lotes de forma assíncrona.

Buscamos dignificar o resultado das respostas exibidas aos usuários, numa tratativa mais elegante que um erro HTTP de código "genérico" ao usuário.