[Em correção] Perda de conexão SDK com portal

#1

Boa tarde,

Em bots de testes que tenho deixado no ar 24h, tenho percebido algumas quedas de conexão entre o serviço (C#) com a plataforma Blip. Acredito que tenham ocorrido devido a instabilidades na internet de meu servidor, sem relação propriamente com a plataforma.

Porém, observo que nestas ocorrências o bot fica offline (consultando no portal e fica sem responder, claro) e não retorna a funcionar mesmo depois do restabelecimento da internet. Muitas vezes estas quedas são rápidas, logo sendo restabelecida a conexão de internet. Apenas volta a funcionar ao reiniciar o serviço. Neste momento, parece que é refeita a conexão com a plataforma e volta a funcionar, entregando todas as mensagens acumuladas ao serviço.

Pergunto se vocês já passaram por situação assim ou teriam alguma dica de como eu poderia contornar isto, por exemplo com alguma consulta periódica para testar conexão entre o serviço C# e a plataforma Blip e alguma forma de reconectar, restabelecendo a comunicação entre estes lados.

Obrigado.

#2

Estou com um problema semelhante ao seu, estou fazendo diversos testes no meu Bot, entretanto, algumas vezes tenho alguns problemas para conectar, hoje pela tarde me deparei com isso diversas vezes, precisei tentar 2, 3, 4x até conectar realmente, sem alterar nada no código. Acredito que a plataforma esteja com algumas instabilidades.

#3

Olá @Fernando_Bellin,

isso não deveria estar acontecendo, uma vez que todos os nossos SDKs possuem reconexão automática.
Poderia me enviar o nome do pacote que você instalou (via nuget) e qual a versão?

Só pra que você tenha uma ideia, todos os bots criados através do Builder são hospedados através do SDK c#.

#4

Olá Rafael,

Os pacotes que tenho instalados nos projetos são estes:
Take.Blip.Client - 0.5.135
Take.Blip.Client.Console - 0.5.135

Para simular isto, consigo testar da seguinte forma:

  • inicio o serviço no meu PC
  • tudo funciona normalmente: mensagens, retorno, etc.
  • removo o cabo de rede do meu PC
  • as mensagens param de ser entregues (claro!)
  • reconecto o cabo de rede do meu PC
  • o serviço permanece off e as mensagens acumuladas e até mesmo as novas não são entregues ao serviço
  • volta a funcionar apenas quando paro e inicio novamente o serviço no meu PC

Claro que a remoção do cabo de rede é algo apenas para teste, mas ela simula a instabilidade da internet que por vezes ocorre. Alguns dias simplesmente o bot estava fora do ar, pois ocorreu alguma falha na rede durante a madrugada, por exemplo. Nestes dias, depois que nossos usuários começaram a reclamar que o serviço não estava respondendo, reiniciamos e serviço e tudo volta ao normal.

#5

Olá @Fernando,

obrigado pelas informações.
Acabei de replicar o cenário que você descreveu e identifiquei um problema na aplicação inbox - responsável pelo armazenamento das mensagens recebidas pelo bot quando o mesmo encontra-se offline.
Já estamos tratando esse problema e assim que tudo estiver reestabelecido te avisarei.

Entretanto não consegui reproduzir o problema de reconexão automática. Durante todos os meus testes, sempre que disconecto o host da rede e reconecto o bot volta a funcionar normalmente.
Consegue me enviar mais evidencias sobre esse problema? Log do serviço no servidor por exemplo.
Você utiliza host Windows? Se sim, confira no EventHandler da máquina se existe algum problema durante a reconexão.

#6

Testei mais algumas vezes e em algumas delas realmente voltou a funcionar depois de reconectar. Geralmente quando a interrupção foi por poucos segundos. Mas quando testei mais tempo (30 segundos antes de reconectar) o serviço simplesmente fica travado. Neste caso, ao tentar parar o serviço gera este log abaixo.

Sim, estou usando Windows, nos logs de eventos aparece algo com RestartManager para o serviço quando ele consegue reconectar. Porém nada aparece quando não volta ao religar a conexão.

Não tenho muito conhecimento em C#, passamos a utilizar para a plataforma Blip. Caso tenha alguma dica de como posso gerar mais informações que sejam relevantes, posso testar aqui sem problemas.

Stopping application…
Application failed:
System.IO.IOException: Unable to transfer data on the transport connection: Uma tentativa de conexão falhou porque o componente conectado não respondeu
corretamente após um período de tempo ou a conexão estabelecida falhou
porque o host conectado não respondeu. —> System.Net.Sockets.SocketException: Uma tentativa de conexão falhou porque o componente conectado não respondeu
corretamente após um período de tempo ou a conexão estabelecida falhou
porque o host conectado não respondeu
— End of inner exception stack trace —
at System.Net.Security.SslStreamInternal.EndRead(IAsyncResult asyncResult)
at System.Net.Security.SslStream.EndRead(IAsyncResult asyncResult)
at System.Threading.Tasks.TaskFactory1.FromAsyncTrimPromise1.Complete(TInstance thisRef, Func3 endMethod, IAsyncResult asyncResult, Boolean requiresSynchronization) --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Lime.Transport.Tcp.TcpTransport.<ReceiveAsync>d__25.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Lime.Protocol.Network.ChannelBase.<ConsumeTransportAsync>d__66.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at Lime.Protocol.Network.ChannelBase.<ConsumeTransportAsync>d__66.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Lime.Protocol.Network.ChannelBase.<ReceiveFromBufferAsync>d__751.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Lime.Protocol.Network.ChannelBase.d__62.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Lime.Protocol.Client.ClientChannel.d__8.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Lime.Protocol.Client.OnDemandClientChannel.d__29.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Take.Blip.Client.BlipClient.d__12.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Take.Blip.Client.Activation.Bootstrapper.StoppableWrapper.d__2.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Take.Blip.Client.Console.ConsoleRunner.d__2.MoveNext()

#7

@Fernando_Bellin,

Problema 1: Perda de mensagens

Analisamos o que você reportou e este problema ocorre somente quando a conexão do cliente é finalizada de forma “suja” (ex: interrupção da conexão, travamento do cliente, etc. Esses casos são extremamente raros). Neste caso, o cliente não envia o pacote FIN na camada TCP e por consequência o servidor não consegue determinar que a conexão está fechada.

Normalmente nesses cenários, o servidor envia alguns pings para os clientes inativos e fecham as conexões após 4 minutos de inatividade. Após estes 4 minutos, o servidor efetivamente mata a conexão e as mensagens passam a cair no inbox.

Problema 2: Reconexão

Gostaria muito que voçê me enviasse os logs do EventViewer (no nível da sua aplicação) do seu servidor caso o mesmo ocorra novamente. Além disso nos envie todas as configurações do seu SO (Sistema Operacional)
Este link apresenta um passo a passo de como visualizar problemas no EventViewer.

#8

Olá Rafael,

Ok, achei que existiria alguma instrução ou evento que pudesse colocar na aplicação para gerar logs no EventViewer para monitorar este caso.

Bom, eu isolei meu PC da rede interna da empresa (servidores/proxy/etc.) para tentar isolar ao máximo a aplicação. Então conectei via WiFi (conexão mais direta que não passa pelo proxy ou firewall). Porém o resultado é o mesmo: simplesmente quando desligo o WiFi do PC, o chatbot para de responder (claro) e ao reconectar, tudo volta a funcionar menos o chatbot.

Estou testando em modo debug e na aplicação eu gero logs no console assim que recebo qualquer mensagem, antes mesmo de tratar alguma coisa. Mesmo assim, nestes casos nada é exibido no log. Como se o chatbot ficasse travado. E ao solicitar parada do serviço no console, gera aquelas mensagens de erro que postei acima.

No EventViewer o único log para gerado neste momento é este abaixo “DNS Client Events”. Não sei se tem relação com o problema, pois aparenta ser problema no DNS, porém todo restante como internet funciona normalmente:

Falha do sistema ao fazer registros de recurso (RRs) do host (A ou AAAA) para o adaptador de rede
com as configurações:

Nome do Adaptador: {8212F054-ECBD-41CE-B694-710BEB0F248E}
Nome do Host: Desenv1
Sufixo de Domínio Primário: aspin.com
Lista de servidores DNS:
192.168.25.1
Atualização enviada ao servidor: 216.69.185.11:53
Endereço(s) IP:
192.168.25.28

O sistema não pôde registrar esses RRs durante a solicitação de atualização devido a um problema do sistema. Você poe repetir manualmente o registro DNS do adaptador de rede e de suas configurações, digitando “ipconfig /registerdns” no prompt de comando. Se os problemas persistirem, contate o administrador do servidor DNS ou de sistemas de rede. Consulte os detalhes do evento para obter informações sobre códigos de erros específicos.

Utilizo Windows 10 Pro
Versão 1709

#9

Olá…

Peço desculpas em reviver o tópico, mas temos alguma novidade? Meu bot fica offline (claro, devido a alguma instabilidade de conexão) e não reconecta novamente. Ele só volta a funcionar quando reinicio meu pod.

Aaaah… estou usando os mesmos pacotes que o @Fernando_Bellin.

#10

Olá @Eduardo_Germano, sem problemas.

Passamos por algumas instabilidades nos últimos 2 dias. Acredito que este problema tenha relação.

Me avise se o problema persistir. :wink:

#11

Olá Pacheco, Jóia?

Passamos e encontrar esse problema no ambiente de desenvolvimento e também em alguns casos no ambiente na AWS.

Li todos os posts desse tópico e gostaria de pedir a implementação de um evento(inclusão de um novo listener) para que possamos identificar na aplicação o insucesso da reconexão e forçar a desconexão e conectar novamente. Processo semelhante aos itens que os colegadas citaram nesse forum.

Qualquer dúvida me avise!

#12

Olá @Cassyo_Okino,

sua sugestão já foi adicionada no BLiP Ideas.
Obrigado!