Content von URL lesen

[noisebreath]

Hi

ich möchte den konnten einer über URL angegebenen txt datei in mein Java Program lesen.
Ich habe gesehen, dass ich das zeile für zeile über den BufferedReader machen kann.

BufferedReader in = new BufferedReader(new InputStreamReader(connection.getInputStream()));

Das führt aber dazu, dass er bei jeder Zeile eine neue Anfrage an den Server schickt. In meinen Augen crazy, weil ich 10000 Anfragen bei 10000 Zeilen schicke. Ich hab versucht das ganze dann über die read methode zu lösen in dem ich stück für stück den inhalt der seite hole die 1.469.747 Byte groß ist:

BufferedReader in = new BufferedReader(new InputStreamReader(conn.getInputStream()));
// loop reading as long as their is content left
char[] arr = new char[1024];
in.read(arr, 0, conn.getContentLength());
byte[] bytes = new String(arr).getBytes("ISO-8859-1");'\t');

Aber auch diese Lösung scheint nicht die richtige zu sein. Ich finde die char array größe von 1024 willkürlich von mir gewählt. Ausserdem gehen dadurch noch immer mehr als genug Anfragen raus.

Hat jemand hierfür eine Lösung?

greez noise

 

[TKausL]

Eigentlich sollte nur eine Anfrage rausgehen.

Zeig doch mal etwas mehr code.

 

[ARadauer]

schleife... solange nicht null daher kommt, kannst du weiterlesen und musst nicht immer wieder einen request senden...

URL url = new URL("http://www.java-forum.org");
		URLConnection connection = url.openConnection();
		BufferedReader in = new BufferedReader(new InputStreamReader(connection.getInputStream()));
		String line = null;
		while ((line = in.readLine()) != null) {
			System.out.println(line);
		}

loop reading as long as their is content left

loop also schleife... macht mit while oder for in java....

 

[noisebreath]

Hm.. komisch.. das ist sehr merkwürdig.. ich habe folgende zwei Arte programmiert gehabt

// get URL content
			URL url = new URL(object.getFeedUrl());
			URLConnection conn = url.openConnection();

			reader = new CSVReader(new InputStreamReader(conn.getInputStream(), "ISO-8859-1"), '\t');
			line = reader.readNext();
			googleProductCategory = Arrays.asList(line).indexOf("google produktkategorie");
			productType = Arrays.asList(line).indexOf("produkttyp");
			gtin = Arrays.asList(line).indexOf("gtin");
			
			String content = StringUtils.join(line, '\t');
			// add google category to products
			while ((line = reader.readNext()) != null) {
				content += StringUtils.join(line, '\t') + System.getProperty("line.separator");
			}
			reader.close();

und

URL url = new URL(object.getFeedUrl());
			URLConnection conn = url.openConnection();
			Reader reader = new InputStreamReader(conn.getInputStream(), "ISO-8859-1");
			char[] buf = new char[1024];
			int read;
			StringBuffer sb = new StringBuffer();
			int i = 0;
			while((read = reader.read(buf)) > 0) {
				sb.append(buf, 0, read);
				++i;
			}

In beiden Fällen zeigt mir Wireshark, dass bei jedem neuen schleifendurchlauf packete zwischen der destination ip und mir geschickt werden.

Verstehe ich hier was falsch? Euer Beispiel läuft doch im Prinzip gleich ab...

 

[Bernd Hohmann]

Ei joh... Du machst den Stream auf und liest häppchenweise ein.

Natürlich erzeugt das dann auch häppchenweise Traffic auf tcp/ip.

Die Anfragen (die Du vermutlich meinst) sind mutmaßlich nur die Requests die nächsten Daten nachzuschieben - der lokale Buffer des tcp/ip Stacks ist nicht sonderlich gross.

Bernd

 

[noisebreath]

Ja das verstehe ich glaube ich, aber kommt das nicht einer DoS-Attacke gleich, wenn die Menge der Daten groß ist? Bei 11000 lines die ich hole sind dass ja dann 11000 requests..

 

[Bernd Hohmann]

Es sind keine Requests (die Anforderung "ich will diesen Content" hast Du ja genau 1x am Anfang gestellt) sondern einfach nur wegpollen der bereitgestellten Datenpakete.

TCP/IP funktioniert in etwa so, dass der Datenstrom in Pakete von ca. 1500 Bytes zerlegt wird und in jedem Paket steht drin "wo komme ich her, wo muss ich hin, welches Paketnummer in der Reihe habe ich" so dass beim Ausfall einer Leitung die restlichen Pakete völlig unsichtbar für den Benutzer über eine andere Strecke laufen können. Die einzelnen Pakete werden nochmal in ein grösseres Bündel gestopft ("TCP Receive Window") und in einem Rutsch über die Leitung geschickt. Wenn das Bündel vollständig beim Empfänger angekommen ist, quittiert er das gegenüber dem Absender und das nächste Bündel geht über die Leitung.

Was Du da bei Wireshark siehst ist also der Normalfall.

Wenn Du die Daten in einem Rutsch haben möchtest, dann muss dem Absender gesagt werden "Hey, mein TCP Receive Window ist riesengroß - schick mal alles komplett". Das geht via Socket.setReceiveBufferSize(), ist aber nicht ratsam da bei einem Fehler innerhalb des Bündels das gesamte Bündel neu geschickt werden muss und noch andere Seiteneffekte hat (zb. muss der Sender mitspielen).

Ich würde es einfach so lassen und mich daran erfreuen, dass TCP/IP funktioniert.

Bernd

 

[noisebreath]

Danke für die Antwort, jetzt is es klar

Ich hab eine weiterführende Frage dazu. Ist die größe der datei von der ich lesen kann in irgendeiner form begrenzt? Denn wenn ich folgendermaßen auslese liest er nicht ganz durch:

                        String content = "";
			int test = 0;
			while ((line = reader.readNext()) != null) {
				content += StringUtils.join(line, '\t') + System.getProperty("line.separator");
			}
			reader.close();

er hört bei 11400 von 11600 Zeilen mitten in der Zeile auf, ohne dass er einen Fehler wirft.

lg

 

[Bernd Hohmann]

Glaskugel: StringUtils.join verschluckt sich und wirft den Fehler nicht weiter. Was ist das für ein Reader, denn readNext() kenne ich so ad hoc nicht?

Bei der Menge an String-"addition" die Du machst könntest Du auf einen StringBuilder ausweichen. Den Line-Separator könnte man sich vor der Schleife einmalig holen.

Bernd

 

[tröööt]

@Bernd
was für ein totaler blödsinn ...
nur weil du auf deinem system den buffer "stückweise" liest heißt das nicht das der server munter die daten am stück sendet und dafür vom stack die jeweiligen bestätigungs-pakete die es bei TCP nun mal gibt auch bekommt ...

genau so funktioniert jede andere art und weise von lesen von daten in java ... und da hier mit einem BufferedReader gearbeitet wird der eh einiges an daten zusätzlich puffert würde der von dir beschriebene effekt erst bei recht großen daten zum tragen kommen ... wenn überhaupt ...

klar ist der buffer des OS nicht unendlich groß ... maximal freier RAM + swap ... aber in aller regel verarbeitet man daten aus einem InputStream weit schneller als diese überhaupt verfügbar sind ... zumindest sollte man das tun ... ansonsten gibts n datenstau ...

natürlich ist das was TO macht nicht gerade sinnvoll alles in EINEN String quetschen zu wollen und dafür nicht mal StringBuilder zu nutzen ... hier sollte man die daten deutlich besser verarbeiten ...
auch das die datei nur die größe von gut 1 1/2 MB hat ... naja ... dann macht man halt n byte-array mit passender größe und liest es komplett in den RAM (was der BufferdReader bereits tun sollte) ...

ich weis zwar nicht in was für welten du lebst (da man ja aus anderen threads dein alter auf irgendwas zwischen 40 und 50 gut eingrenzen kann) ... aber wir leben nicht mehr in zeiten von 28,8k modems und analoger datenverarbeitung ... sondern (fast) im jahr 2013 ... und heutzutage ist es kein problem für ein normales system mal eben ein paar hunderte MB von nem server im RAM zu halten ... damit irgendwas anzustellen und das ergebnis dann auf ne recht schnelle platte rauszuschreiben ... zu dem sind die anbindungen normaler netz-zugänge bereits im bereich 100MBit/s und aufwärts (was bei der meisten netzwerk-hardware die nur mit 100MBit/s brutto arbeitet nicht viel sinn macht) ...

das von TO beschriebene problem lässt also eher auf implementierungsfehler schließen oder meinet wegen auf irgendwelche bugs anstatt auf "normales" verhalten ... denn "normal" wäre (entsprechend implementiert) das das OS erstmal einen großteil (falls möglich alles) des response im RAM auf dem stack zwischen hält und dann an die VM leitet anstatt für jedes 1kB paket einen neuen request zu machen

 

[nillehammer]

@trööt: Lies Dir Bernd Hohmann's Erklärung nochmal genau durch. Dann wirst Du merken, dass sie nicht so falsch ist, wie Du denkst. Auch wenn Du bei der Erfindung von TCP/IP wahrscheinlich noch garnicht auf der Welt warst (Deine Posts lassen auf ein Alter unter 18 schließen), lohnt es sich diese "alten" Technologien zu verstehen. Denn obwohl wir nicht mehr im Zeitalter von 28k-Modems leben, hat sich an der Funktionsweise dieser Protokolle nicht sehr viel geändert.

 

[Bernd Hohmann]

@Bernd
was für ein totaler blödsinn ...

[ ] Du hast TCP verstanden

Machen wir es entlich amtlich....

Merkbefreiung: (laut Amtsblatt)
====================

Die nachstehend eindeutig identifizierte Lebensform

Name                 : trööt
Vorname              : träät
Geburtsdatum         : 01.04.1995
Geburtsort           : Hinter dem Mond
Personalausweisnummer: ____________________
 [x] keine Ausweisnummer, da imaginäre Person

ist hiermit für den Zeitraum von

	[_]  6 Monaten
	[_] 12 Monaten
	[_] 24 Monaten
	[x] unbefristet

davon befreit, etwas zu merken, d.h. wesentliche Verhaltensänderungen bei der Interaktion mit denkenden Wesen zu zeigen.

Die Einstufung der o.a. Person nach dem amtlichen Index für Merkbefreiungen liegt bei dem Äquivalent von

	[_] einem Mensaessen vom Vortag
	[_] drei Hartkeksen in löslichem Kaffee
	[_] einer Kiste Schwarzbrot in Dosen
	[x] einem kleinen Hamster im Laufrad
	[_] einem Quadratmeterstück Torfmoos während einer
 	     sechswöchigen Sommerdürre
	[_] einem Container erodiertem Sandstein
	    (Streusandqualität)

Die ausgesprochene Merkbefreiung erlischt mit dem Ablauf des

	[x] der o.a. Frist, beginnend mit dem Zeitpunkt der Ausstellung
	[_] __.__.20__
	[_] der vollständigen Erosion der körperlichen
	    Bestandteile der o.a. Lebensform

und gilt, sofern die o.a. Lebensform durch das nachstehende Kennzeichen als merkbefreit zu identifizieren ist:

	[_] eine rote Plastiknase
	[_] olives Stoffstück mit weißem Rand, auf der Schulter
	    zu tragen
	[x] die Lebensform ist durch den Gesichtsausdruck
	    zweifelsfrei als unbefristet merkbefreit zu
	    erkennen.

Befund nach Prüfung durch das Bundesamt:

	[_] kurzzeitiger Aussetzer durch Übermüdung des Merkerit-Detektionsstudenten. Einstellung
	   eines zweiten solchen wird empfohlen.
	[x] Überdurchschnittlich hohe Konzentrationen an Trollium und Merkerit
	[_] Alle bekannten Therapien sind wirklungslos geblieben
	[_] Der Patient erreichte eine Trollpunktzahl von ___ Punkten gem. der Trollnorm ISO-330209
	[_] Bei Versuchstieren wurde ein Penko-Grad von _.__ Penko geschätzt
	[x] Der Merkbefreite ist im Besitz von 20 oder mehr zugeworfenen Fischen gem. Norm HB-FT-2000

Die o.a. Lebensform ist durch den Erwerb dieses Merkbefreiungsscheins automatisch für die folgenden Tätigkeiten
qualifiziert:

	[_] Markierungshütchen bei Abmarkierungsarbeiten auf
	    Bundesautobahnen
	[_] Garderobenständer und Regenschirmständer in
	    Restaurants bis zu, aber nicht eingeschlossen, 3
	    Sterne
	[_] Regelstab in Schwerwasserreaktoren
	[x] Markierungsstab für das Fahrwasser im Nationalpark
	    Wattenmeer
	[_] Landschaftsmerkmal/Orientierungshilfe in der Wüste
	    Gobi

Die Merkbefreiung für die o.a. Lebensform wurde in einem öffentlichen Merkbefreiungsverfahren ausgesprochen und ist nach Ablauf der Einspruchsfrist von 17 Sekunden rechtskräftig.

Datum         Unterschrift  Dienstsiegel
17.12.2012    hohmann       (*.*)

Stirnabdruck des Merkbefreiten
 ** platsch **

 

[noisebreath]

Der Reader ist au.com.bytecode.opencsv.CSVReader, könnte es daran liegen?

Btw. Wie wäre dass den mit nem Stringbuffer am besten?

 

[Bernd Hohmann]

Der Reader ist au.com.bytecode.opencsv.CSVReader, könnte es daran liegen?

So auf den ersten Blick nicht. Der macht intern einen BufferedReader, liest eine Zeile ein, zerhackt das dann nach den Kommata und liefert ein String-Array zurück was Du dann mit .join(....) in eine Tab-Separierte Zeile mit CRLF wirfst.

Das Problem scheint eher hinter dem geposteten Stück Code zu liegen. Schreibst Du das dann in eine Datei? Dann würde ich mal versuchen statt erst einen riesen String zu bauen das sofort Zeilenweise mit einem PrintWriter wegzuschreiben und gleichzeitig auf die Konsole auszugeben.

"mitten in der Zeile" aufhören klingt nach einem unverhoffen .close() auf der Senderseite, habe aber nicht den leisesten Verdacht woran das liegen mag.

StringBuffer/StringBuilder?

Ungefähr so:

StringBuilder strb = new StringBuilder();
String line[]=null;
while ((line = reader.readNext()) != null) {
   for (int i=0;i<line.length;i++) {
     strb.append(line[i]);
     strb.append("\t");
   }
   strb.append(System.getProperty("line.separator"));
}
System.out.println(strb.toString());

Bernd

 

[noisebreath]

Danke für die Antwort Bernd! Leider bin ich noch immer nicht schlauer, selbst wenn ich nur sowas tue:

                        int test = 0;
			while ((line = csvReader.readNext()) != null) {
				System.out.println("Zahl " + test);
				test++;
				System.out.println(line);
			}

Liest er mir die gleiche Anzahl aus, wie vorher. Bricht auch an der gleichen Stelle ab. Ich bin da mittlerweile vollkommen ratlos. Ist das ein Problem von der "anderen Seite", also von der Seite die ich abfrage?

greez

 

[noisebreath]

noch etwas.. was mir aufgefallen ist, ist dass die Lösung mit dem Stringbuilder viel performanter ist. Das Stringutils.join scheint ein richtiger performancefresser zu sein..

 

[Bernd Hohmann]

Liest er mir die gleiche Anzahl aus, wie vorher. Bricht auch an der gleichen Stelle ab. Ich bin da mittlerweile vollkommen ratlos. Ist das ein Problem von der "anderen Seite", also von der Seite die ich abfrage?

Das vorletzte was mir jetzt noch einfällt: Lass mal den csvReader weg und lies direkt von der URL mit einem BufferedReader und zähle die Zeilen:

BufferedReader br = new BuffferedReader(....);
while ((line = br.readLine()) != null) {
	System.out.println("Zahl " + test);
	test++;
	System.out.println(line);
}

Du kannst mir aber auch einen abgespeckten Source mit der URL geben (wenns "top secret"ist per PM) und ich probier das hier mal aus - was Netzwerk angeht bin ich noch einigermassen in Übung.

Zu den StringUtils: da wird noch der alte StringBuffer von Java 1.1 genutzt. Ist der StringBuilder in gelb, nur sind alle Methoden mit "synchronized" versehen und das zieht sich bei vielen kleinen Einzeloperation fürchterlich hin. Warum StringBuffer (und auch Vector) jemals so gestaltet wurden wissen nur die Götter

Meine persönliche Meinung: ich halte mich von allen Apache-Tools (selbst dem Webserver) gerne fern weil da überwiegend nur Features draufgepackt werden wärend der Unterbau verrottet. Ok - manchmal kommt man nicht daran vorbei (zb. Lucene), aber es ist auch vieles dabei was man nicht mit paar Handgriffen selber besser und im Laufzeitverhalten schneller hinbekommt.

Bernd

 

[noisebreath]

Hi Bernd,

tatsächlich geht es mit dem Bufferedreader einwandfrei, dass heisst da muss ein problem im CSVReader herrschen.. -.-

Danke nochmal für die Hilfe und Diskussion!

lg
noise

 

[Bernd Hohmann]

Problem mittlerweile gefunden?

Bernd