Neustart von idFTP nach EIdConnClosedGracefully?

[andreasm82]

Super, vielen Dank!

dann werde ich das Update besser noch lassen. Aber ich schaue ab und an mal in den Changelog herein.


Dass es keine richtige Anlaufstelle gibt, um bugs zu melden, ist schade.
Vielleicht sollte ich bugs einfach dem einen Entwickler melden, der ja auch hier im Forum aktiv ist?

[DelTurbo]

Zitat:

Zitat von andreasm82 (Beitrag 1036883)

Vielleicht sollte ich bugs einfach dem einen Entwickler melden, der ja auch hier im Forum aktiv ist?

Kannst du gerne versuchen. Ich habe das auch mehrmals gemacht. Es reichte nicht zu sagen da ist ein fehler. Ich musste jedesmal extra ein demo-prog machen. Es wurde auch kein Thread für diese sachen erzeugt, wo andere hätten mitlesen können bzw. auch was hätten zu sagen können. Das ging alles über PN. Das ist relativ zermürbend. Ich fix die sachen selber. Geht wesentlich schneller. Allerdings nur die sachen, die mir in meiner software auffallen.

Da der fehler den du hast nicht reprodizierbar ist, sehe ich schwarz. Ich hatte den fehler zwar auch, aber ich hab ihn einfach selber so gut es ging und meinen bedürfnissen nach rausgehohlt.

Gruss

[Assertor]

Hallo,

jetzt stolper ich über diese Thread und hier steht so viel falsches, dass geht ja langsam nicht mehr :shock:

Fangen wir mal ganz oben an:

Exceptions sind nicht nur Fehler, sondern eben Exceptions. Es macht auch einen Unterschied zu erwähnen, ob diese Silent Exceptions sind, d.h. nur in der IDE beim Debugger auftreten oder auch bei einer Ausführung ohne Debugger.

Zum Thema Indy, Exceptions und "Connection Closed Gracefully" gibt es seit vielen Jahren (über Google gut zu findende) Infos:
http://www.indyproject.org/KB/index....exceptions.htm
http://www.indyproject.org/KB/index....ngeidconnc.htm
http://www.swissdelphicenter.ch/en/showarticle.php?id=1

Die "Warnung" von DelTurbo zu Updates nach einer gewissen Revision halte ich für falsch, es ist einfach seine persönliche Meinung.

Was ich nicht stehen lassen kann:

Zwei Dinge, die DelTurbo ausführt, sind wissentlich falsch
1. Indy hätte keine Anlaufstellen
2. Es wären auf meinen Wunsch keine Threads zu den Themen erzeugt worden

DelTurbo selbst wollte damals PNs statt Threads, dies klingt in obigem Post nun anders... Über die Kommunikationsprobleme zwischen DelTurbo und mir und Erwartungshaltung an OpenSource von DelTurbo gibt es hier genügend Threads.

Desweiteren bin ich hier zwar vertreten, aber ich kann nicht jede PN dazu beantworten. Dies ergibt sich schon aus der Anzahl der Delphi und Indy Installation, hier in der DP auch aus der Anzahl der Forenmitglieder und Indy Themen.

Nun zu den Anlaufstellen:

Projektseiten und Issue Tracker
http://code.google.com/p/indyproject/issues/list
http://indy.codeplex.com/workitem/list/basic

Newsgroups
Bei Atozed (NNTP): news://news.atozedsoftware.com/
Bei Embarcadero (NNTP): embarcadero.public.delphi.internet.winsock
Bei Embarcadero (Web): https://forums.embarcadero.com/forum.jspa?forumID=74

Bugreports
Es gehört zum guten Ton in der Delphi bzw. Entwickler Community ein reproduzierbares Demo bzw. genügend Code für Bugreports bereitzustellen. Da muß auch ich durch, wenn ich etwas im QualityCentral bei Embarcadero als Delphi-Fehler erfasse. Informationen über Betriebssystem, Delphi Version, Testumgebung etc.pp. gehören auch dazu.

Für offizielle Bugreports mit Delphi ausgelieferter Indy Versionen, bitte das QualityCentral nutzen.

Dort werden Bug Reports auch von Embarcadero gelegentlich bewertet. Viele werden auch geschlossen, weil die Qualität einfach zu schlecht ist (eben kein Quelltext, keine deutliche Sprache und/oder kein Demo). Soviel zum Thema mühselig - so ist das nunmal...

Webseite
Die Webseite (http://indyproject.org/) ist bekannt, aber ebenso wie bei den Kollegen vom JEDI Team hoffnungslos veraltet. Dies liegt an mangelnder Unterstützung durch Freiwillige. Summa summarum ist Indy ein OpenSource Projekt mit starker gegenseitiger Abhängigkeit zu Embarcadero Delphi & C++ Builder. Das Team ist inzwischen bei uns aber leider sehr klein.

Das Problem mit Connection Closed Gracefully
Änderungen wie von DelTurbo vorgeschlagen, z.B. die Try-Catch-A, verdecken nur ein anderes Problem. Dies ist nicht zu empfehlen, da ja die Möglichkeit besteht diese Exception mit Grundlagenwissen Delphi abzufangen und die Komponente z.B. neu zu instanzieren.

Übrigens: Bei einer Designtime Komponente läßt sich z.B. mit GExperts IDE Add-In per Mausklick die Design- in eine Runtime-Komponente "verwandeln". Dann steht einer Wiederverwendung doch nichts im Weg.

Das aktuelle Problem ist bekannt, tritt sporadisch auf. Erfasst ist ein ähnlich gelagertes Problem z.B. bereits hier:
http://code.google.com/p/indyproject...il?id=81&can=1

Sehr zu empfehlen ist der Thread "Connection closed gracefully redux" von unserem Team Mitglied Remy Lebeau (TeamB) im EMBT Forum:
https://forums.embarcadero.com/messa...ssageID=166101

Es also schon helfen, nach dem Disconnect den Input Buffer zu leeren (egal ob HTTP oder FTP Komponente):

Delphi-Quellcode:

if Assigned(IOHandler) then IOHandler.InputBuffer.Clear;

Delphi 6 & 7
Im Moment liegt die Priorität bei der Entwicklung auf aktuellen Versionen, insbesondere im Bereich Vereinfachung und besserer Support für Unicode.

Delphi 6 & 7 laufen zu 99,9% nicht anders als Delphi 2009 & 2010. Die Probleme, die es gibt beziehen sich auf die Komponenten Packages. Das wird später gefixt, da hier sowieso eine größere Änderungen kommen soll.

Hier im Forum waren trotzdem genügend in der Lage, dies Installationsprobleme selbst zu lösen und nutzen aktuellste Revisionen von Indy mit D7 (Components-By-Code geht sowieso).

Zum Projekt
Leider kann bei einer so großen Library wie den Indys vieles nicht "mal eben so" gefixt werden, da viele Änderungen andere Teile in Mitleidenschaft ziehen könnten. Das Prinzip "1 Bug gefixt, dafür 10 neue offen" bringt ja niemandem etwas. Es gibt gerade bei WinSocks einige Fallstricke, über die Entwickler die mal eben eine "Internet Kompo" bauen wollen, immer wieder fallen.

Die vergangenen Probleme von DelTurbo beziehen sich auf Komponenten, IRC und FXP (FTP Server-zu-Server), die leider keine hohe Verbreitung bei unseren Nutzern haben und deswegen auch keine hohe Priorität. Dafür fehlt einfach die Zeit und die Manpower. Sie sind eine einfache Beigabe, insbesondere weil weder das eine noch das andere einer Normierung unterliegt. Bei FTP, HTTP, SMTP etc gibt es ja im Gegenzug die bekannten RFCs.

Seit kurzem haben wir alle offenen Bugs im internen Bugtracker von Embarcadero schließen können, darüber freue ich mich zumindest sehr.

@Andreas: Ich hoffe, das hat dir etwas weiter geholfen. Melde Dich gerne bei Google Code oder CodePlex an, um unseren Issue Tracker zu füllen. Das gilt natürlich auch für alle anderen.

Gruß,
Assertor

[andreasm82]

Vielen Lieben Dank für die ausführliche Antwort.

Ich habe das "if Assigned(IOHandler) then IOHandler.InputBuffer.Clear;" mal hinzugefügt und werde es testen.
Ich melde mich dann die Tage nochmal, ob es problemlos funktioniert oder doch noch Probleme auftreten sollten.

Zitat:

Delphi 6 & 7 laufen zu 99,9% nicht anders als Delphi 2009 & 2010. Die Probleme, die es gibt beziehen sich auf die Komponenten Packages. Das wird später gefixt, da hier sowieso eine größere Änderungen kommen soll.

Gut zu wissen, denn ich wollte gestern das aktuelle Indy tiburon testen, doch ich kriege es unter Delphi 7 nicht zum laufen. Die Installation der Packages klappt nicht auf dem gewohnten Weg.

[andreasm82]

Och mann... der Hinweis mit dem leeren des Input Buffers funktioniert bei FTP.
Ich hatte seitdem keine Probleme mehr.

Doch bei HTTP tritt dies noch immer auf:

Zitat:

10.08.2010 08:52:29 Downloading http page from 192.168.31.8
10.08.2010 08:52:29 Error DownloadHTTPPage: EIdSocketError:Socket Error # 10054
Connection reset by peer.

Hier mein momentan verwendeter Code:

Zitat:

HttpPageContent := form1.idhttp1.Get(WebPage);

form1.idhttp1.Disconnect(true);
if Assigned(form1.idhttp1.IOHandler) then form1.idhttp1.IOHandler.InputBuffer.Clear;

hierbei habe ich das ganze schon mit und ohne dem disconnect,
mit und und ohne inputbuffer.clear probiert...

[andreasm82]

Hallo,

auf dem FTP Server fand ich eben zufällig:

Indy10Tiburon_4448.zip
Indy10_4452.zip

Ist die Indy10_4452 eine neue, aktualisierte, stabile Version?
Was sagt die Zahl 4452 aus ? Versionsnummer?
Dann wäre Indy10_4452 ja aktueller als Indy10Tiburon_4448 oder?
Welche Änderungen gibt es in Indy10_4452 gegenüber der letzten 10er version?
(im changelog steht nur etwas von merged usw)

Ich nutze ja derzeit noch die 4017 von Tiburon. Und scheinbar hängt sich mein Programm damit noch ab und an auf. Ich würde daher gerne auf was stabiles wechseln.

[Assertor]

Hallo Andreas,

Zitat:

Zitat von andreasm82 (Beitrag 1056195)

auf dem FTP Server fand ich eben zufällig:

Indy10Tiburon_4448.zip
Indy10_4452.zip

Ist die Indy10_4452 eine neue, aktualisierte, stabile Version?
Was sagt die Zahl 4452 aus ? Versionsnummer?
Dann wäre Indy10_4452 ja aktueller als Indy10Tiburon_4448 oder?
Welche Änderungen gibt es in Indy10_4452 gegenüber der letzten 10er version?
(im changelog steht nur etwas von merged usw)

Ich nutze ja derzeit noch die 4017 von Tiburon. Und scheinbar hängt sich mein Programm damit noch ab und an auf. Ich würde daher gerne auf was stabiles wechseln.

Wir hatten gerade in den letzten Tagen den Merge gemacht, d.h. ja die Indy10_4452.zip ist aktueller. Der Tiburon Branch wird etwas später gelöscht (später, damit Nutzer Ihre Links anpassen können). Etwas offiziell stabiles gibt es nicht, weder von uns noch von Embarcadero. Das sieht man ja nicht zuletzt daran, dass die Shipping Versionen von Indy in D2009 oder D2010 Bugs enthalten, die bei uns schon gefixt sind (z.B. E-Mail Attachment Namenproblem in der D2009 Indy Version, in D2010 z.B. das FTP Binary-Mode Problem).

"Irgendwann" wird es wieder etwas offiziell stabiles geben, aber da ist noch viel zu tun. Ist natürlich auch die Frage, wie definiert sich stabil. Source ohne Bugs gibt es ja wohl nirgendwo (siehe bspw. QC), aber wenn stabil in Richtung besser getestet (automatisiert) und mit Setup/Installer geht: das ist geplant.

Ich hoffe, die Info hilft Dir weiter :)

Viele Grüße,
Assertor

[andreasm82]

Vielen Dank!

[andreasm82]

Zitat:

if Assigned(form1.idhttp1.IOHandler) then form1.idhttp1.IOHandler.InputBuffer.Clear;

So etwas benötige ich auch für die Indy ICMP Client komponente, mit der ich Gegenstellen anpingen möchte. Habe es aber nicht herausgefunden.

Dummerweise kommt es nämlich auch mit dieser Komponente alle paar Tage mal vor, dass das Programm die Fehlermeldung bzgl. connection closed gracefully ausspuckt. Es hilft dann nur ein Neustart des Programms... dies möchte ich jedoch abfangen.

Kennt jemand so einen Befehl?

[andreasm82]

EIdConnClosedGracefully Meldungen kommen mit neueren Indy Versionen inzwischen nicht mehr. Das scheint intern behoben zu sein.

Was jedoch merkwürdig ist:
Ab und an kommt beim Herunterladen einer Datei über FTP die Meldung "EIdReplyRFCError:Syntax error in parameters or arguments".
Aber es handelt sich jedes mal um den gleichen Aufruf und die gleiche Datei.
Ich nutze derzeit Indy10_4571

Woran könnte dies liegen?

Auszug aus meiner Logdatei des Programms:

Code:

28.02.2011 11:22:27 FTP connected to 192.168.31.12
28.02.2011 11:22:31 Downloading m110228.txt...
28.02.2011 11:22:32 Error DownloadData: EIdReplyRFCError:Syntax error in parameters or arguments.