FileNotFoundException - Details herausbekommen

[== != equals]

Ich lese ab und zu eine URL:

URL url = new URL(adresse);
Reader is = new InputStreamReader( url.openStream() );
BufferedReader in = new BufferedReader( is );

Leider erhalte ich auf meinem Server oft nach paar Sekunden Warten eine FileNotFoundException mit der korrekten URL. Die URL an sich ist aber erreichbar und mit einem PHP-Script, das die URL aufruft, habe ich das Problem nicht.

Die Beschreibung zur Fehlermeldung habe ich mir durchgelesen, sagt mir aber nicht so viel. Gibt es Möglichkeiten, genaueres zur Ursache festzustellen? Gibt es Einstellungen im System, die eine regelmäßige URL-Abfrage blockieren könnten?

 

[ARadauer]

Gibt es Einstellungen im System, die eine regelmäßige URL-Abfrage blockieren könnten?

Der Server kann erkennen ob du mit dem Browser oder etwas anderes daher kommst. (Stichwort Agent) da kann natürlich blockiert werden..

 

[== != equals]

Genau so einen konkreten Grund möchte ich als Gewissheit haben. Warum wird FileNotFound geliefert (das klingt für mich nach 404), wenn die Datei an sich erreichbar ist, aber z.B. der Zugriff nicht erlaubt wird?
Manchmal funktioniert es ja, manchmal nicht.

 

[Gast2]

Timeout? ... evt. dauert die Antwort manchmal etwas länger als Java warten will ... kommt keine Antwort - kommt der Timeout und damit die Exception ... ggf. liefert eine InnerException weitere Details

 

[r.w.]

Genau so einen konkreten Grund möchte ich als Gewissheit haben. Warum wird FileNotFound geliefert (das klingt für mich nach 404), wenn die Datei an sich erreichbar ist, aber z.B. der Zugriff nicht erlaubt wird?
Manchmal funktioniert es ja, manchmal nicht.

Der Programmierer des PHP-Skriptes hat aus dem Skript natürlich Möglichkeiten
Zugriffe zu filtern (z.B. je IP max. n Zugriffe innerhalb 30 Sekunden, o.ä.).
Er hat auch die Möglichkeit, Dir einen beliebigen HTTP-Fehlercode vorzugaukeln.
Ist also auf diese Art schwierig festzustellen, warum der Fehler auftritt.

VG ROlf

 

[MarderFahrer]

Also ich habe hier bei einem Apache cxf einen Timeout von "0L" angegeben weil mir der bei größerern Sachen schon mal Error geschmissen hat. Waren allerdings keine FileNotFound soweit ich das noch weiß.

Long timeout = 0L;
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
httpClientPolicy.setConnectionTimeout(timeout.longValue());
httpClientPolicy.setReceiveTimeout(timeout.longValue());

 

[Murray]

Leider erhalte ich auf meinem Server oft nach paar Sekunden Warten eine FileNotFoundException mit der korrekten URL.

Kannst du den kompletten Stack-Trace der Exception posten?

 

[Murray]

Also ich habe hier bei einem Apache cxf einen Timeout von "0L" angegeben weil mir der bei größerern Sachen schon mal Error geschmissen hat.

Mit "unendlichen Wartezeiten" wäre ich vorsichtig - das ist eigentlich nie sinnvoll. Angenommen, der Server "klemmt" aus irgendwelchen Gründen (z.B. ein Deadlock), dann wird der Request solange warten (und im Client Resourcen verbraten), bis jemand im Server das Problem behebt. Deshalb: Timeouts lieber auf große Werte als auf unendlich setzen, wenn man möchte, dass zwar verspätete Antworten noch empfangen werden, ohne dass man damit bei überhaupt nicht mehr reagierenden Servern auch den Client blockiert.

 

[MarderFahrer]

Mit "unendlichen Wartezeiten" wäre ich vorsichtig - das ist eigentlich nie sinnvoll. Angenommen, der Server "klemmt" aus irgendwelchen Gründen (z.B. ein Deadlock), dann wird der Request solange warten (und im Client Resourcen verbraten), bis jemand im Server das Problem behebt. Deshalb: Timeouts lieber auf große Werte als auf unendlich setzen, wenn man möchte, dass zwar verspätete Antworten noch empfangen werden, ohne dass man damit bei überhaupt nicht mehr reagierenden Servern auch den Client blockiert.

Generell ja, aber in meinem Fall arbeitet das Programm nur in einem Kontext mit Hudson. Hudson hat seine eigenen Timeouts und auf diese Weise muss man nicht an zwei Stellen Timeouts dimensionieren.

 

[Gast2]

Generell ja, aber in meinem Fall arbeitet das Programm nur in einem Kontext mit Hudson. Hudson hat seine eigenen Timeouts und auf diese Weise muss man nicht an zwei Stellen Timeouts dimensionieren.

Grundsätzliche Entwicklungsregel (bei mir): "der Andere" macht grundsätzlich Fehler - nur ich bin perferkt ... also gehe bei den Timeouts davon aus das Hudson da einen Fehler macht und Dein Programm blockiert ... Du kannst keine Annahmen von einem Programmverhalten machen was Du nicht vom Quelltext her kontrollieren kannst ... gut - Hudson wird funktionieren, ich habe aber schon APIs gehabt wo Fehler drinnen waren (und mir in meinem Programm einen Wolf gesucht)

anderes Problem ... ein Bagger reist bei Deiner Anfrage das (Netzwerk-)Kabel auseinander ... bei Hudson kommt der Timeout - und bei Dir?

 

[MarderFahrer]

Da Hudson in meinem Fall dafür da ist das Programm zu starten und das Programm etwas macht was vorraussetzt das Hudson korrekt funktiert hat, passt das schon so bei mir.

"Der andere macht Fehler" ist da ein bisschen fehl am Platz. Ich sehe das mehr wie eine Kette von Abläufen und im Ersten Teil ist der Timeout für die gesamte Kette definiert. Sollte es einen Fehler schon im Ersten Teil geben, wäre der Rest der Abläufe sowieso nicht zu gebrauchen und wird darum auch gleich konsequent abgebrochen.

Also:
Hudson hat Fehler = Workspace wird gar nicht oder nicht korrekt gebuildet.
Dann muss mein Programm sowie sämtliche Test Skripte auch nicht mehr laufen.

 

[== != equals]

Guten Abend,

es hat etwas gedauert, aber inzwischen besucht mich das Problem wieder.

Kannst du den kompletten Stack-Trace der Exception posten?

Angehängt habe ich hier einmal den Stack von der langen Ladezeit, Stack von der Exception selbst kann ich auch gern machen.
Hilft das?

 

[Murray]

Stack von der Exception selbst kann ich auch gern machen.

Das wäre gut.

 

[== != equals]

Angehängt habe ich hier einmal den Stack von der langen Ladezeit, Stack von der Exception selbst kann ich auch gern machen.

Das wäre gut.

So, hat etwas gedauert. Angehängt die Exception.
Die Klassen Exportforce und Klammuser sind von mir.