DOMConnection hängt sich auf

[horstmeyer]

Hallo zusammen,

ich suche nach einer Möglichkeit wie man eine DCOMConnection-Verbindung testen kann oder wie man bei DCOMConnection einen timeout setzen kann. Folgende Funktion funktioniert leider nicht:

Delphi-Quellcode:

function Verbindungstest(bMeld:boolean):boolean;
begin
  result:=true;
  try
    Form1.DCOMConnection1.ComputerName:=Form1.edComputername.Text;
    Form1.DCOMConnection1.Connected:=true;
    Form1.DCOMConnection1.Connected:=false;
    if bMeld then
      Showmessage('Verbindung erfolgreich!');
  except
    result:=false;
    if bMeld then
      Showmessage('Verbindung fehlgeschlagen!');
  end;
end;

Wenn der DCOM-Server sich aufgehangen hat, dann bleibt der DCOM-Client an der Stelle "Form1.DCOMConnection1.Connected:=true;" hängen. Wie kann ich das verhindern. Danke für einen hilfreichen Tipp.

Viele Grüße
Horst

[klaus schaaff]

Hallo Horst,

das ist eine schwere Frage. Zum Einen Deine function Verbindungstest ist sehr fragwürdig. bMeld gibt schon vor Eintritt in die function vor, was das Ergebnis sein wird, obwohl Connected:= false davor die Verbindung schließen wird.

Gut, der Hänger tritt bei Connected:= true auf. Wenn du da vorher in den Compiler-Optionen -> Use Debug DCUs einstellst, könntest Du genauer Debuggen (tiefer), wo der Hänger entsteht.

Es gibt verschiedenste DCOMConnection-Verbindungen, die dann unterschiedliche Einrichtungen erfordern. Läuft bei Dir der Dienst Windows Management Instrumentation service. Wie sieht das Setting up WMI connections aus. Emba erklärt auch verschiedenes: TCP/IP sockets, use TSocketConnection, To connect to remote application servers using HTTP, use the TWebConnection component. To connect to application servers using SOAP, use TSoapConnection.

Schau mal das:

https://support.quest.com/kb/4295692...-host-machines

Gibst Du eine gültige Anmeldung bei Computername ein? Wie sieht die Registrierung des Servers auf der Client-Maschine aus.

Da sind leider zu viele Fragen offen.

Zumindest solltest Du über Win-Bordmittel WMI Control irgendwas sehen.

Nachtrag: Hier noch einige Links zum Thema:

https://d36j349d8rqm96.cloudfront.ne...COM_manual.pdf

https://www.softwaretoolbox.com/dcom...l-overview.pdf

https://entwickler-ecke.de/topic_Reg...dbe435a56d1e14



Liebe Grüße
Klaus Schaaff

[mjustin]

Zitat:

Zitat von horstmeyer (Beitrag 1520529)

ich suche nach einer Möglichkeit wie man eine DCOMConnection-Verbindung testen kann oder wie man bei DCOMConnection einen timeout setzen kann.

Funktioniert der Verbindungsaufbau lokal (wenn der Server läuft)?
Und wenn der lokale Server nicht gestartet ist, dauert es dann auch 'ewig' oder kommt sofort eine Fehlermeldung?
Im Netz findet man Hinweise auf einen 6 Minuten Timeout für DCOM. Ein Workaround wäre, anstatt einer TDCOMConnection eine TSocketConnection (oder eine TWebConnection) zu verwenden. Diese verwenden dann das normale TCP/IP Timeout.
Für einen einfachen Test könnte man mit einer beliebigen Socket-Komponente versuchen, den serverseitigen Port anzusprechen. Dabei kann man ebenfalls das TCP/IP Comnnect-Timeout setzen.

[horstmeyer]

Bei TSocketConnection kann ich keine Eigenschaft "Timeout" finden. Mir geht es ja "nur" darum bevor ich eine Funktion auf dem DCOM-Server aufrufe zu prüfen, ob die Verbindung antwortet und wenn nach einer gewissen Zeit keine Antwort kommt, eine Meldung ausgeben wie beispielsweise "DCOM-Verbindung antwortet nicht". Gibt es nicht vielleicht auch eine Art dcomping? Ich habe die Windowsfunktion rpcping gefunden, aber die gibt auch eine Meldung zurück wenn der Server gerade nicht gestartet ist...

[Uwe Raabe]

Bei COM und DCOM muss der Server ja gar nicht gestartet sein um eine Verbindung aufzumachen. Der wird im Zweifelsfall automatisch gestartet. Was soll dann da vorab geprüft werden, was nicht auch auf ein Connect hinausläuft?

Du kannst aber immerhin prüfen, ob ein Ping an den Zielrechner erfolgreich ist. Das garantiert zum Einen aber nicht, dass dann auch der DCOM-Server antwortet, und zum Anderen ist ein fehlschlagender Ping auch kein sicheres Indiz, dass der Rechner wirklich nicht erreichbar ist. Manche Rechner antworten einfach nicht auf ein Ping.