Timeout in Windows-Dienst erhöhen



  • Ich habe einen Windows-Dienst mit WebMethods in einer ASMX-Datei. Alles funktioniert sehr gut. Mit einer Client-Anwendung kann ich mich ohne Probleme mit dem Dienst verbinden und eine Funktion aufrufen.

    Wenn die Funktion jedoch länger als 1,5 Minuten für ihre Ausführung braucht, dann kommt im Client folgende Exception an:

    System.Web.Services.Protocols.SoapHeaderException: Server unavailable, please try later

    Es ist nicht tatsächlich so, dass der Server nicht erreichbar ist. Die Funktion läuft wunderbar und gibt das Ergebnis an den Client zurück, wenn ihre Ausführung nicht allzu lange benötigt. Das Problem existiert nur, wenn die Funktion länger als 1,5 Minuten braucht.

    Leider habe ich im Dienst eine Funktion, die nunmal sehr lange für ihre Ausführung braucht.

    Deshalb würde ich gerne wissen: Wie kann ich den Timeout-Wert für den Aufruf von WebMethods in Windows-Diensten erhöhen?

    Ich habe schon gegooglet, aber habe immer nur Themen gefunden, wo es darum ging, dass der Startup des Dienstes nicht funktionierte.

    Das Timeout-Property der Proxy-Klasse höher setzen funktioniert übrigens auch nicht.



  • Das Timeout musst du beim Client definieren. Da ich davon ausgehe, dass du einen normalen SOAP-Proxy hast, schau mal nach der Property Timeout.

    // EDIT: Was bedeuted das Timeout höher setzen funktioniert nicht? Bedenke das das Timeout in Millisekunden angegeben wird.



  • Ich weiß, dass das Timeout in Millisekunden angegeben wird. Ich habe 300000 gesetzt, aber das interessiert ihn überhaupt nicht. Er springt immer nach 1,5 Minuten ab.

    Das ganze passiert auch beim Debuggen: Ich starte den Dienst in einer Anwendung in Visual Studio, setze einen Breakpoint und rufe die Methode vom Client aus (welcher eine separate Anwendung ist) auf.
    Das Programm stoppt beim Breakpoint und ich kann ganz normal durchdebuggen. Sobald ich aus der Funktion raus bin, bekommt der Client seine Antwort.

    Aber: Wenn ich mir mit dem Debuggen zu lange Zeit lasse, dann kann es auch passieren, dass mir das Ding beim nächsten Druck auf F10 sofort eine Exception wirft, obwohl in der Funktion selbst überhaupt nichts ist, was eine Exception verursachen würde. Eben weil der Dienst durch mein Trödeln beim Debuggen in den Timeout gelaufen ist und jetzt unmittelbar die Ausführung abbricht.

    Also gehe ich schon davon aus, dass die Timeout-Geschichte im Dienst und nicht im Client konfiguriert werden muss.

    Ich kann ja am Dienstag, wenn ich wieder auf der Arbeit bin, mal eine WebMethod schreiben, die jede Sekunde was in eine Datei schreibt und sich niemals beendet. Und dann rufe ich diese Funktion auf und gucke, ob sie immer noch weiterschreibt, wenn der Client bereits den Timeout empfangen hat.
    Wenn nein, dann ist es definitiv der Dienst, der hier einen Riegel vorschiebt, und nicht nur der Client, der irgendwann mit Warten aufhört.



  • Nachtrag: In der Zwischenzeit wäre ich natürlich trotzdem für weitere Ideen dankbar.



  • Klaus B. schrieb:

    Ich kann ja am Dienstag, wenn ich wieder auf der Arbeit bin, mal eine WebMethod schreiben, die jede Sekunde was in eine Datei schreibt und sich niemals beendet. Und dann rufe ich diese Funktion auf und gucke, ob sie immer noch weiterschreibt, wenn der Client bereits den Timeout empfangen hat.
    Wenn nein, dann ist es definitiv der Dienst, der hier einen Riegel vorschiebt, und nicht nur der Client, der irgendwann mit Warten aufhört.

    Gute Idee.
    Ich gehe nämlich davon aus dass das Timeout doch im Client zu suchen ist. Serverseitige Timeouts sind eher selten.



  • Falls das doch stimmt: Wieso bringt die Einstellung des Timeout-Property nichts? Hast du da eine mögliche Idee?



  • Nö, sorry, keine Idee dazu.
    Ausserdem hab' ich übersehen dass der Exception-Typ System.Web.Services.Protocols.SoapHeaderException ist. Das klingt dann doch eher nach einem Serverseitig erzeugten Fehler.
    Was mich immer noch wundert, aber die MSDN meint das wäre so.



  • Eine weitere Sache, die ich mal ausprobieren werde: Den Timeout-Wert im Client auf einen geringen Wert setzen. Wenn er dann vorher rausspringt, und dann noch mit einer anderen Meldung als der oben stehenden, liegt mein eigentliches Problem wirklich am Dienst.



  • Wenn es am Dienst liegt, würde ich davon ausgehen, dass du dort entweder mit einer Datenbank oder einem weiteren Dienst kommunizierst und der Timeout dort zu gering bemessen ist.

    Denn eines ist klar, das reine Kommunikationstimeout zwischen Client und Service gibt definitiv der Client an.



  • @inflames2k
    Manche Server bzw. Server Frameworks forcieren ein eigenes Timeout. z.B. um den Server vor Abfragen zu "schützen" die einfach zu lange dauern.
    Standard Apache+PHP Installationen tun das wenn ich mich nicht irre z.B.
    Ich meine mich zu erinnern dass es auch bei ASP (ohne .NET) so war.

    Und wenn die Exception (SoapHeaderException) vom Framework korrekterweise erzeugt wird, dann muss es fast ein serverseitiges Problem sein. Weil SoapHeaderException heisst ja dass der Server zurückgemeldet hat dass es ein Problem gab.
    Was impliziert dass der Client nicht seinerseits vorzeitig abgebrochen hat - sonst hätte er ja keine Antwort erhalten.


Anmelden zum Antworten