c# - Subprime las excepciones abortadas en el servicio wcf
threadabortexception thread-abort (2)
Me he encontrado con este problema y se debió a un uso inadecuado de la clase cliente.
Lo que estaba sucediendo es que cuando se ha creado una instancia de una clase de cliente, no liberaría los recursos, lo que provocaría una reducción en el rendimiento. Se producirá una excepción muy inútil "Se está abortando el hilo". Esto se resolvió creando una clase auxiliar que el aliado genérico creó un objeto cliente y luego implementó el constructor y el método de eliminación correctamente.
Algunas excepciones de IIS no son muy útiles o verdaderas respecto a la causa real del problema, pero para llegar al fondo de lo que se hizo para resolver mi problema fue mirar los registros de IIS. Específicamente " Reglas de seguimiento de solicitudes fallidas "
Espero que esto ayude, puedo entender su frustración porque fue un dolor de cabeza resolver.
Tengo un servicio WCF (construido en .NET framework 3.5) alojado en IIS 6.0.
El flujo del código es el siguiente
- El cliente (que es otro servicio web) llama al servicio WCF
- Los servicios de WCF invocan un hilo para hacer el procesamiento en segundo plano y responden a la persona que llama de inmediato.
- El hilo de fondo después de completar todo el procesamiento, devuelve la llamada al hilo. Esta llamada es básicamente una solicitud HTTP ya que el cliente es un servicio web.
Estoy probando la carga de mi servicio WCF para definir los umbrales. La observación es la siguiente:
Alrededor de 3 iteraciones de 1024 solicitudes realizadas al servicio WCF dentro de 1 minuto pasan con éxito. El tiempo necesario para completar cada iteración es de unos 25-30 minutos. Sin embargo a partir de la 4ta iteración se observan fallas masivas. Alrededor del 50% de las solicitudes fallan con la siguiente excepción.
Exception-Thread estaba siendo abortado.
Rastro de pila
21_10_2016_09_30_52,9:30:52 AM,Information,Thread name- apSwTTbLTETfwT3y Stack trace in ProcessTestConversion method - at System.Threading.WaitHandle.WaitOneNative(SafeHandle waitableSafeHandle, UInt32 millisecondsTimeout, Boolean hasThreadAffinity, Boolean exitContext)
at System.Threading.WaitHandle.InternalWaitOne(SafeHandle waitableSafeHandle, Int64 millisecondsTimeout, Boolean hasThreadAffinity, Boolean exitContext)
at System.Threading.WaitHandle.WaitOne(Int32 millisecondsTimeout, Boolean exitContext)
at System.Net.LazyAsyncResult.WaitForCompletion(Boolean snap)
at System.Net.Connection.SubmitRequest(HttpWebRequest request, Boolean forcedsubmit)
at System.Net.ServicePoint.SubmitRequest(HttpWebRequest request, String connName)
at System.Net.HttpWebRequest.SubmitRequest(ServicePoint servicePoint)
at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)
at System.Net.HttpWebRequest.GetRequestStream()
.
.(My function calls stack trace)
.
.
Los cambios que intenté resolver estos problemas son los siguientes:
<behavior>
<serviceThrottling maxConcurrentCalls="2000"
maxConcurrentInstances ="2400"
maxConcurrentSessions ="400"/>
</behavior>
en web.config
<system.web>
<compilation debug="false" />
<httpRuntime executionTimeout="1800"/>
</system.web>
en web.config
<system.net>
<connectionManagement>
<add address = "*" maxconnection = "100" />
</connectionManagement>
</system.net>
en web.config
ServicePointManager.DefaultConnectionLimit = 100; (Change in code)
He establecido la propiedad IdleTimeout del grupo de aplicaciones en 0 como lo sugieren muchas personas en StackOverflow.
Donde quiera que se usen los arroyos, he dispuesto en todos los lugares. Así que todas las corrientes están cerradas.
¿Puede alguien decirme quién está abortando los subprocesos y por qué y hay algún medio o herramienta para rastrear la causa de la iniciación del aborto de subprocesos?
Tengo la misma cosa de cara antes. La solución fue liberar recursos / clientes una vez que se terminó su alcance mediante la implementación del método Dispose .
El problema existe ya que la declaración de using C # para limpiar automáticamente los recursos cuando se usa un cliente escrito no tiene éxito y cualquier excepción lanzada está enmascarada por la disposición implícita que come la excepción real y lanza alguna otra excepción como el tiempo de espera u otras excepciones.
La declaración "utilizando" de C # da como resultado una llamada a Dispose (). Esto es lo mismo que Cerrar (), que puede generar excepciones cuando se produce un error de red. Debido a que la llamada a Dispose () ocurre implícitamente en el corchete de cierre del bloque "utilizando", es probable que esta fuente de excepciones pase desapercibida para las personas que escriben el código y leen el código. Esto representa una fuente potencial de errores de aplicación. (de MSDN )
Debes liberar recursos como:
try
{
...
client.Close();
}
catch (CommunicationException e)
{
...
client.Abort();
}
catch (TimeoutException e)
{
...
client.Abort();
}
catch (Exception e)
{
...
client.Abort();
throw;
}
De esta manera, no solo puede encontrar la fuente real de excepción y también liberar recursos cuando se produce alguna excepción.
Otra solución alternativa puede ser implementar Dispose como:
/// <summary>
/// Calculator Client
/// </summary>
public partial class CalculatorClient : IDisposable
{
#region IDisposable implementation
/// <summary>
/// IDisposable.Dispose implementation, calls Dispose(true).
/// </summary>
void IDisposable.Dispose()
{
Dispose(true);
}
/// <summary>
/// Dispose worker method. Handles graceful shutdown of the
/// client even if it is an faulted state.
/// </summary>
/// <param name="disposing">Are we disposing (alternative
/// is to be finalizing)</param>
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
try
{
if (State != CommunicationState.Faulted)
{
Close();
}
}
finally
{
if (State != CommunicationState.Closed)
{
Abort();
}
}
}
}
/// <summary>
/// Finalizer.
/// </summary>
CalculatorClient()
{
Dispose(false);
}
#endregion
}
Fuentes :
MSDN MSDN