Para dar una descripción general rápida, estoy intentando insertar varios cientos de registros de forma asincrónica en nuestra base de datos mediante llamadas individuales en mssql npm. Sin embargo, mientras usaba una versión anterior 3.3.0 de mssql, a veces no recibía una devolución de llamada del npm. Actualicé mssql a 4.0.4 y todavía no recibo devoluciones de llamada. Lo rastreé hasta este npm.
Después de processPreLoginResponse, se envía a tls. Luego pasa a SentTLSSSLNegotiation. Por alguna razón, después de unos cientos de registros una vez que llega aquí, se llama a socketEnd. Luego pasa a Final, se llama a la función enter, se llama a cleanupConnection (sin parámetros), borra la conexión y solicita los temporizadores, cierra la conexión, se llama a socketClose y luego intenta hacer la transición a Final nuevamente, y la función enter no se llama, y parece simplemente colgar allí indefinidamente.
¿Alguna idea de por qué se llama a socketEnd en primer lugar o por qué nunca aparece en mi código para que pueda manejarlo?
jstephens7
Todos 5 comentarios
Estamos teniendo este problema exacto usando una base de datos azul. Podemos recrear fácilmente el problema después de aproximadamente 4 horas de ejecutar una función azul en un temporizador de 1 segundo. ¿Hay algo que podamos hacer para ayudar? Este es un gran problema para nosotros y nos encantaría recibir algún tipo de actualización sobre este tema.
landondavidson
en 2 abr. 2018
Hola @landondavidson , perdón por la respuesta tardía, ¿te importaría compartir el repositorio para este problema?
Teníamos el número 574 que abordó ConnectionError intermitente en Azure DB, se lanzó en la tediosa v2.1.0, la mayoría de los paquetes de agrupación de conexiones usan una versión anterior del controlador tedioso, ¿puede verificar si su dep está usando el controlador más reciente?
Suraiya-Hameed
en 31 may. 2018
@ v-suhame, no vemos ningún ConnectionError. El enchufe simplemente se cierra sobre nosotros en el proceso de conexión. Acabo de enviar una solicitud de extracción con la corrección que hemos puesto en producción durante las últimas dos semanas. Este es un sitio web con una carga bastante pesada y el error ha desaparecido por completo con la agrupación de conexiones volviendo a intentar la conexión después de ser informado.
landondavidson
en 4 jun. 2018
@landondavidson @ jstephens7 https://github.com/tediousjs/tedious/pull/763 se fusionó y lanzó como [email protected] .
Háganos saber si todavía tiene algún problema. Mientras tanto, cerraré este tema. 🙇
arthurschreiber
en 11 jul. 2018
La solución anterior me está funcionando, pero decidí ejecutar Wirehark para intentar ver el tráfico de red que conduce al error en primer lugar. Pude reproducir el problema dos veces mientras ejecutaba el seguimiento.
No estoy seguro del significado de alguna parte de lo que recibí, así que incluiré lo que noté en común entre las dos veces que ocurrió el error.
En ambas ocasiones tuvimos un PSH ACK y FIN ACK con un tamaño de ventana de 66560.
Después de eso, ambas veces tuvimos un RST ACK.
Entonces parece que estaba comenzando la próxima negociación TLS (saludo del cliente, saludo del servidor ... mensaje de protocolo de enlace cifrado)
Después de eso, en ambas ocasiones comenzó a enviar datos de la aplicación y obtuvimos una "alerta cifrada" de TLS seguida de ACK y se había llamado a socket.end (no más tráfico TLS / TCP).
jstephens7
en 4 feb. 2019
Temas relacionados
malarcherc
·
9Comentarios
arthurschreiber
·
8Comentarios
gladmustang
·
6Comentarios
tvrprasad
·
6Comentarios
anthonylau
·
8Comentarios
Comentario más útil
@landondavidson @ jstephens7 https://github.com/tediousjs/tedious/pull/763 se fusionó y lanzó como
[email protected].Háganos saber si todavía tiene algún problema. Mientras tanto, cerraré este tema. 🙇