WSACancelBlockingCall-Ausnahme

Ok, ich habe eine seltsame Ausnahme, die ausgelöst von meinem code, war stört mich seit Ewigkeiten.

System.Net.Sockets.SocketException: A blocking operation was interrupted by a call to WSACancelBlockingCall
   at System.Net.Sockets.Socket.Accept()
   at System.Net.Sockets.TcpListener.AcceptTcpClient()

MSDN ist nicht sonderlich hilfreich auf dieser : http://msdn.microsoft.com/en-us/library/ms741547(VS.85).aspx und ich weiß nicht einmal wissen, wie Sie mit der Problembehandlung beginnen diese. Es ist nur geworfen 4 oder 5 mal am Tag, und nie in unserer test-Umgebung. Nur in der Produktion, Standorten und ALLEN Standorten.

Habe ich gefunden, viele Beiträge, Fragen über diese Ausnahme, aber nicht die tatsächliche definitive Antworten auf das, was verursacht Sie, und wie zu behandeln oder zu verhindern.

Der code läuft in einem separaten hintergrund-thread, der die Methode startet :

public virtual void Startup()
    {
     TcpListener serverSocket= new TcpListener(new IPEndPoint(bindAddress, port));    
        serverSocket.Start();

dann Lauf ich eine Schleife dabei, alle neuen verbindungen, wie Arbeitsplätze in einem separaten thread-pool. Es wird komplizierter, weil der app-Architektur, aber im Grunde:

   while (( socket = serverSocket.AcceptTcpClient()) !=null) //Funny exception here
    {
         connectionHandler = new ConnectionHandler(socket, mappingStrategy);
         pool.AddJob(connectionHandler);
    }
  }

Von dort aus die pool gibt es eigene threads, die kümmern sich um jeden job in einem eigenen thread, getrennt.

Mein Verständnis ist, dass AcceptTcpClient() ist ein blockierender Aufruf, und irgendwie winsock sagen, den thread zu stoppen, blockieren und fortsetzen.. aber warum? Und was soll ich tun? Nur die Ausnahme abfangen und ignorieren es?

Gut, ich denke einige andere Threads, die Schließung der Steckdose, aber es ist sicherlich nicht von meinem code.
Was ich gerne wissen würde ist: ist das socket geschlossen, indem der verbindende client (auf der anderen Seite der Buchse) oder ist es geschlossen, von meinem server. Weil, wie es ist, in diesem moment, wenn diese Ausnahme Eintritt, wird es shutsdown meine listening-port, effektiv schließen meines service. Wenn dies geschehen ist, von einem entfernten Standort, dann ist es ein großes problem.

Alternativ, das könnte auch einfach den IIS-server heruntergefahren meine Anwendung, und somit der Streichung meine hintergrund-threads und blockierenden Methoden?

InformationsquelleAutor der Frage Radu094 | 2008-08-28

c#sockets

36

Ist es möglich, dass der serverSocket geschlossen aus einem anderen thread? Das wird zu dieser Ausnahme.

InformationsquelleAutor der Antwort TimK

Dies ist mein Beispiel-Lösung zu vermeiden WSAcancelblablabla:
Definieren Sie Ihren thread als Globale, dann können Sie mit invoke-Methode wie diese:

private void closinginvoker(string dummy)
    {
        if (InvokeRequired)
        {
            this.Invoke(new Action<string>(closinginvoker), new object[] { dummy });
            return;
        }
        t_listen.Abort();
        client_flag = true;
        c_idle.Close();
        listener1.Stop();
    }

Nachdem Sie es aufrufen, den thread schließen zuerst, dann die forever-loop-flag, so ist es block weiter warten (wenn Sie es haben), dann schließen Sie tcpclient dann stoppen Sie die Zuhörer.

InformationsquelleAutor der Antwort Nikolaus Very Permana

4

Dies könnte geschehen, auf einer serverSocket.Stop(). Die ich rief, Wann immer Dispose genannt wurde.

Hier ist, wie mein exception-handling für den listen-thread sah, wie:
```
try
{
    //...
}
catch (SocketException socketEx)
{    
    if (_disposed)
        ar.SetAsCompleted(null, false); //exception because listener stopped (disposed), ignore exception
    else
        ar.SetAsCompleted(socketEx, false);
}
```
Nun, was geschah, war, dass jeder so oft die Ausnahme die auftreten würde, bevor _disposed wurde auf true gesetzt. So die Lösung für mich war, alles zu machen, dass thread-sicher.

InformationsquelleAutor der Antwort
3

Gleiche hier!
Aber ich habe herausgefunden, dass die ReceiveBuffer auf 'server-side' überschwemmt wurde, von den Kunden!
(In meinem Fall eine Reihe von RFID-Scannern, die gehalten spamming TagCode, statt den Versand bis zum nächsten TagCode kommt)

Es geholfen, zu erhöhen, die ReceiveBuffers und konfigurieren Sie den Scanner...

InformationsquelleAutor der Antwort blogga

Mehr vor kurzem sah ich diese Ausnahme bei der Verwendung von HttpWebRequest um eine große Datei, und die Timeout-Zeit übergeben wurde.

Verwenden Sie den folgenden code so lange, wie Sie Ihre upload-Zeit > 3 Sekunden, wird es diesen Fehler verursachen, soweit ich das sehen konnte.

string path = "Reasonably large file.dat";
int bufferSize = 1024;
byte[] buffer = new byte[bufferSize];
System.Net.HttpWebRequest req = (HttpWebRequest)System.Net.HttpWebRequest.Create("Some URL");
req.Method = "PUT";
req.Timeout = 3000; //3 seconds, small timeout to demonstrate
long length = new System.IO.FileInfo(path).Length;
using (FileStream input = File.OpenRead(path))
{
    using (Stream output = req.GetRequestStream())
    {
        long remaining = length;
        int bytesRead = 0;
        while ((bytesRead = input.Read(buffer, 0, (int)Math.Min(remaining, (decimal)bufferSize))) > 0)
        {
            output.Write(buffer, 0, bytesRead);
            remaining -= bytesRead;
        }
        output.Close();
    }
input.Close();
}

InformationsquelleAutor der Antwort SimonNZ

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.