Tengo una aplicación ASP.NEt Core 3.1 con frontend Angular 8. Funciona bien cuando está alojado en IIS, pero como lo he movido a un nuevo servidor Ubuntu 18 con Nginx por encima de Kestrel, a veces los procesos en segundo plano de ejecución prolongada dejan de funcionar (IHostedService). Luego, la aplicación se ejecuta para aceptar nuevas solicitudes, por lo que solo se detiene el proceso en segundo plano.
Estos procesos obtienen archivos de los clientes y dan respuestas inmediatas con identificadores de proceso. Los clientes pueden consultar el estado del proceso por su id. Todo ha estado funcionando bien durante meses en IIS, pero la nueva configuración debe tener algunos límites que eliminan estos procesos. Supongo que hay alguna opción de kestrel o nginx que no conozco y que afecta los procesos iniciados por solicitudes http.
¿Qué opciones puedo probar y dónde puedo obtener algunos registros?
He intentado registrar todo desde .net core, pero incluso los registros más detallados son inútiles aquí. Los registros de Nginx tampoco contienen información sobre el proceso detenido.
Aunque la aplicación funciona bien alojada en IIS, traté de encontrar bloques de captura sin ningún resultado y agregué el inicio de sesión en ellos, pero aún nada. ¿Hay algo que pueda agregar a los datos globales de mi aplicación para registrar cualquier excepción manejada o no manejada?
Olvidé decir que uso un Microsoft SQL Server Express local tanto en Windows como en Linux. La instalación de linux Sql Server fue realizada por los documentos oficiales de ms (como dotnet y nginx config, también). La base de datos se restaura a partir de una copia de seguridad del servidor SQL de Windows. La cadena de conexión es la misma con multipleresultsets=true. ¿Hay alguna diferencia que deba conocer?
Para cualquiera que llegue aquí en el futuro: esto fue causado por un error en Microsoft.Data.SqlClient, por lo que tuve que actualizarlo (independientemente de EF Core 3.1.2) de nuget a la versión 1.1.2 más nueva.
Cuando se atascó, tenía dos subprocesos esperando el uno al otro, ambos en SqlClient. Con Solo mi código habilitado, el depurador VS se detuvo en una de mis consultas de linq. La única parte interesante fue que nunca arrojó ninguna excepción y tampoco hubo un evento de punto muerto en el servidor sql. Simplemente esperó allí para que todos los registros estuvieran vacíos.