Announcement

Collapse
No announcement yet.

Indy TCPClient-Komponente. Problem mit DoConnectTimeout!

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Indy TCPClient-Komponente. Problem mit DoConnectTimeout!

    Hallo Entwicklergemeinde!

    Ich habe ein kleines, unschönes Problem mit der Indy TCPClient-Komponente! Die Komponente TIdTCPClient ist bei mir an einer TIdIOHandlerStack-Komponente gebunden. Ich verwende drei solcher Client-IOHandlerStack Komponentenverbindungen, welche ich nacheinander initialisiere und öffne. Sind die drei zu bindenden Host vorhanden wird alles schön sauber gebunden. Ich löse die Verbindungen zu einem späteren Zeitpunkt. Das Timeout für den Verbindungsversuch habe ich auf 1000 (ms) gesetzt. Bei der ersten Clientverbindung wird das auch sauber umgesetzt: Server nicht da --> 1000 ms Wartezeit --> Exception wird ausgelöst
    Problem:

    Die Clients 2 & 3 welche direkt im Anschluss gebunden werden sollen, benötogen für das Auslösen der Exception ca. 30s !! Beim Debuggen ist mir aufgefallen, dass in der Indy-Unit 'IdIOHandlerStack' eine Prozedur 'ConnectClient' und darin eine eingebundene Prozedur 'DoConnectTimeout()' existiert. In der DoConnectTimeout() wird durch den Aufruf von 'WaitFor()' versucht, das hResult des beendeten Threads zu ermitteln. Und da liegt der Hund begraben! Erst nach ca. 30s melden die Threads anscheinend Ihr Ende, denn so lange dauert es bis die Funktion zurückkehrt.

    Muss ich stattdessen mit einer Client-Komponente arbeiten und diese erst wieder freigeben um Sie mit dem zweiten Host zu verbinden? Wenn die Hosts alle da sind gibt es keinerlei Problem mit Wartezeiten.

    Ich hoffe das Problem ist halbwegs klar geworden!

    Danke für jede Antwort!

    Gruß

    Carsten

  • #2
    Hallo,

    voll aus der Hüfte - aber bringt eine TidAntiFreeze - Komponente etwas?
    Ich habs gleich!
    ... sagte der Programmierer.

    Comment


    • #3
      Hängen im TCP-Schacht!

      Hi tinof!

      Danke für deine Idee, die Komponente 'TidAntiFreeze' hat leider keinerlei
      Auswirkung!

      THX

      Carsten

      Comment


      • #4
        Hallo,

        kann es auch an den Clients liegen, dass 2 /3 z.B. woanders sind als 1?
        Bzw. wenn die Verbindungsreihenfolge statt 1,2,3 z.B. 2,1,3 ist, tritt das Problem dann genauso auf?
        Ich habs gleich!
        ... sagte der Programmierer.

        Comment


        • #5
          Verbindungsreihenfolge

          Hi!

          Sorry für die späte Rückmeldung, bin häufiger bei Kunden in der letzten Zeit!
          Ändere ich die Verbiindungsreihenfolge auf z.B. 2/1/3/4, so bleibt die Anwendung bei der Eingangs beschriebenen Funktion sofort beim Client 2 'kleben'. Beim Client 1 wird die Exception schön brav innerhalb 1000ms erledigt.

          Dürfen denn von einer Anwendung aus mehrere TCP-Clients parallel erzeugt werden?
          (Ich denke mir, warum nicht!?)

          Comment

          Working...
          X