La operación de E/S se ha cancelado debido a una salida de subproceso oa una solicitud de solicitud

Mi aplicación funciona como aplicación de cliente para el servidor de Banco. La aplicación está enviando solicitud y recibiendo respuesta del banco. Esta aplicación es normalmente funciona bien, pero a vecesLa operación de E/S se ha cancelado debido a una salida de subproceso oa una solicitud de solicitud

La operación de E/S ha sido abortada a causa de una salida de subproceso o una aplicación solicitud

error con código de error como 995 está llegando.

public void OnDataReceived(IAsyncResult asyn) 
{ 
    BLCommonFunctions.WriteLogger(0, "In :- OnDataReceived", 
             ref swReceivedLogWriter, strLogPath, 0); 
    try 
    { 
     SocketPacket theSockId = (SocketPacket)asyn.AsyncState; 

     int iRx = theSockId.thisSocket.EndReceive(asyn); //Here error is coming 
     string strHEX = BLCommonFunctions.ByteArrToHex(theSockId.dataBuffer);      

    } 
}

Una vez que este error empiezan a salir de todas las transacciones después de comenzar el mismo error que aparezca, por lo por favor me ayude a solucionar este problema. Si es posible luego con un código de ejemplo

Saludos, Ashish Khandelwal

Fuente

2011-08-29 funsukvangdu

Hay pocos errores de Windows que son tan descriptivos y confiables como ese. No podemos ayudarlo a encontrar el hilo que termina demasiado pronto. Agregue un poco de seguimiento a su código si no puede encontrarlo. –

995 es un error reportado por el IO Completion Port. El error proviene de que intenta continuar leyendo desde el socket cuando lo más probable es que se haya cerrado.

Recibir 0 bytes de EndRecieve significa que el socket se ha cerrado, al igual que la mayoría de las excepciones que arrojará EndRecieve.

Tienes que empezar a manejar esas situaciones.

Nunca ignore las excepciones, se deben a un motivo.

actualización

No hay nada que diga que el servidor hace nada malo. Se puede perder una conexión por muchas razones, ya que la conexión inactiva se cierra mediante interruptor/enrutador/firewall, etc. También se producen fallas en la red.

Lo que digo es que DEBES manejar las desconexiones. La forma correcta de hacerlo es desechar el zócalo e intentar conectar uno nuevo a ciertos intervalos.

En cuanto a la recepción de devolución de llamada de una manera más adecuada de manejar es algo como esto (pseudo código semi):

public void OnDataReceived(IAsyncResult asyn) 
{ 
    BLCommonFunctions.WriteLogger(0, "In :- OnDataReceived", ref swReceivedLogWriter, strLogPath, 0); 

    try 
    { 
     SocketPacket client = (SocketPacket)asyn.AsyncState; 

     int bytesReceived = client.thisSocket.EndReceive(asyn); //Here error is coming 
     if (bytesReceived == 0) 
     { 
      HandleDisconnect(client); 
      return; 
     } 
    } 
    catch (Exception err) 
    { 
     HandleDisconnect(client); 
    } 

    try 
    { 
     string strHEX = BLCommonFunctions.ByteArrToHex(theSockId.dataBuffer);      

     //do your handling here 
    } 
    catch (Exception err) 
    { 
     // Your logic threw an exception. handle it accordinhly 
    } 

    try 
    { 
     client.thisSocket.BeginRecieve(.. all parameters ..); 
    } 
    catch (Exception err) 
    { 
     HandleDisconnect(client); 
    } 
}

la razón de por qué estoy usando tres bloques catch es simplemente porque la lógica de el del medio es diferente de los otros dos. Las excepciones de BeginReceive/EndReceive generalmente indican la desconexión del socket mientras que las excepciones de su lógica no deberían detener la recepción del socket.

Fuente

2011-08-30 07:33:46 jgauffin

Estimados jgauffin, Gracias por su respuesta, pero el problema es que solo la aplicación cliente es de nuestra empresa y el servidor es de algún banco, por lo que si el socket se cierra desde su lado, ¿cómo podemos expresar que este problema es de su lado? maneja esto sin excepción, es decir, como lanza una excepción en endreceive podemos escribir cualquier comando que nos diga que la recepción de datos es 0 – funsukvangdu

lee mi actualización. – jgauffin

@funsukvangdu: ¿Tienes más preguntas? – jgauffin

Tuve el mismo problema con la comunicación RS232. El motivo es que su programa se ejecuta mucho más rápido que el puerto de comunicación (o comunicación en serie lenta).

Para solucionarlo, tuve que comprobar si el IAsyncResult.IsCompleted==true. Si no se completa, entonces IAsyncResult.AsyncWaitHandle.WaitOne()

De esta manera:

Stream s = this.GetStream(); 
IAsyncResult ar = s.BeginWrite(data, 0, data.Length, SendAsync, state); 
if (!ar.IsCompleted) 
    ar.AsyncWaitHandle.WaitOne();

mayoría de las veces, ar.IsCompleted habrá true.

Fuente

2015-03-02 19:40:52 user4624881

¡esto funciona como una magia! Gracias –

Lo que hago cuando sucede es Desactivar el puerto COM en el Administrador de dispositivos y Habilitar nuevo.

Detener las comunicaciones con otro programa o hilo y convertirse en libre para usted.

Espero que esto funcione para usted. Saludos.

Fuente

2015-12-03 15:45:29

Tuve este problema. Creo que fue causado por el hecho de que se abrió el socket y no se reciben datos dentro de un corto tiempo después de la apertura. Estaba leyendo desde una caja serial a ethernet llamada Devicemaster. Cambié la configuración del puerto Devicemaster de "conectar siempre" a "conectar en datos" y el problema desapareció. Siento un gran respeto por Hans Passant, pero no estoy de acuerdo con que este sea un código de error que pueda resolver fácilmente analizando el código.

Fuente

2016-10-13 08:29:55

La operación de E/S se ha cancelado debido a una salida de subproceso oa una solicitud de solicitud

Respuesta

Cuestiones relacionadas