Probleme mit Verbindungsabbruch bei WCF



  • Hi C++ Community,
    Ich stehe vor einem Problem, das mich langsam richtig Nerven kostet. Vielleicht weiß ja bei euch jemand weiter.

    Mein Problem:
    Ich nutze WCF für die Kommunukation von einer Clientanwendung zu einer Serveranwendung.
    Wenn ich versuche einen geöffneten WCF Channel über Close/Abort zu schließen läuft dieser allerdings bis auf das Ende des eingestellten Timeouts weiter (bestätigt durch ANTS Memory Profiler).
    Gibt es eine Möglichkeit den Channel zuverlässig zu schließen, ohne das es hier zu einer Art Memory Leak kommt, da .NET (bzw. der GC) die Objekte, die den Channel halten, nicht verwirft?

    Wäre auch super wenn mir jemand erklären könnte warum das so ist, ob das einen näheren Sinn hat.

    Vielen Dank schonmal



  • Ist dein Server denn erreichbar und ist dein Timeout sehr gross?



  • Yuka13 schrieb:

    Ist dein Server denn erreichbar und ist dein Timeout sehr gross?

    Hi Yuka13,

    Ja!
    Ich versuche gerade den Worst Case nachzubilden, nämlich das der Server praktisch nie erreichbar ist.
    Die Timeouts sind bei mir recht groß, da ich für manche Funktionen die ich auf dem Server ausführe etwas mehr Zeit einplanen muss.

    Ich weiß schon, das ich das Problem mit dem Heruntersetzen der Timeouts begrenzen kann, jedoch ist mir hier nicht ganz klar, warum es dann überhaupt die Möglichkeiten gibt den Channel über Abort/Close zu schließen.



  • Mir ist nicht klar was für ein Problem du hast.

    Permanent leakt hier nichts, d.h. es leakt maximal in dem Sinn dass Abort die Connection/den Channel nicht gleich komplett zusammenräumt, sondern es bis zum Ablauf des Timeout dauern kann bis das Zeug weggeräumt werden kann.

    Hast du vor so schnell so viele Retries zu machen dass das am Client zu einem Problem führt?



  • hustbaer schrieb:

    Mir ist nicht klar was für ein Problem du hast.

    Permanent leakt hier nichts, d.h. es leakt maximal in dem Sinn dass Abort die Connection/den Channel nicht gleich komplett zusammenräumt, sondern es bis zum Ablauf des Timeout dauern kann bis das Zeug weggeräumt werden kann.

    Hast du vor so schnell so viele Retries zu machen dass das am Client zu einem Problem führt?

    Das stimmt, ich habe das Problem, das ich sehr unterschiedliche Netzwerkumbungen habe, das heißt ich benötige manchmal sehr große Timeouts und manchmal nicht.

    Mein Test hat genau das versucht, aber ich denke ein Test sollte das Szenario immer etwas übertreiben.

    Mir geht es darum zu verstehen ob es eine bessere Lösung gibt, als die Timeouts anzupassen. Es funktioniert, aber ich bin damit nicht so wirklich zufrieden.

    Für alle die ein ähnliches Problem haben:
    Bei mir hat das Herunterschrauben des SendTimeouts das Problem "gelöst".
    -> Was irgendwie nachvollziehbar ist, da dieser die asynchrone Anfrage auslaufen lässt.



  • Laut dem was ich mir so ergoogle ist das SendTimeout client-seitig das Timeout für den ganzen Prozess, also inklusive dem Empfangen der Antwort! Also das was du sicher nicht runterschrauben willst.
    Siehe https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/configuring-timeout-values-on-a-binding

    Versuch mal nur das OpenTimeout runterzuschrauben.



  • hustbaer schrieb:

    Laut dem was ich mir so ergoogle ist das SendTimeout client-seitig das Timeout für den ganzen Prozess, also inklusive dem Empfangen der Antwort! Also das was du sicher nicht runterschrauben willst.
    Siehe https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/configuring-timeout-values-on-a-binding

    Versuch mal nur das OpenTimeout runterzuschrauben.

    Ja der war mitunter auch beteiligt.
    Bin jetzt so verblieben, das ich den OpenTmeout und den CloseTimeout möglist klein halte, bei mir jetzt je 2 Minuten.
    Den SendTimeout hab ich etwas heruntergeschraubt, ist jetzt bei 5 Minuten und der ReceiveTimeout hat keine direkte Auswirkung auf mein genanntes Problem, was deine Aussage unterstreicht.


Anmelden zum Antworten