Buffer....

[Icewind]

Hallo, naja das ist jetzt kein Problem weil ich das schon gelöst habe aber wollte meine Erfahrung nur meinen Mitmenschen zur verfügung stellen...

Also ich schreibe gerade ein Programm bei dem ich Daten, unter anderem auch Files, über das Web schicke und so kam es das ich eine Leseschleife in meinem Testclient erstellt habe um das Filesenden zu testen...

die schaut mal so aus:

for(i=0;((i+1)*16384)<file.length();i++)
{
	fin.read(read);                         //einlesen aus einem FileInputStream
	test=new Vector();
	test.add(file.getPath());
	test.add(read);                        //read is ein byte[] mit der größe 16384 also 16kb
	msg=new Message(test,Message.DOWNLOAD_PART);
	oout.writeObject(msg);
}

um den rest eizulesen gab es noch eine Leseoperation.

Tja das Problem daran war nur das immer das gleiche beim anderen Client ankam (es wurde allerdings die richtige Anzahl an bytes übertragen), also baute ich ein das er mir immer einen Teil des Lesearrays ausgibt. Tja da steht auch ,wie nicht anders zu erwarten, immer was anderes drinn. Allerdings würde bei dem letzten Datensatz auch etwas anderes übertragen, und der war ja nicht in der Leseschleife enthalten.

Nach mehreren Minuten herummprobieren kam ich auf die Idee den byte[] neu zu instanzieren und sieheda es funktionier!!!


Gibt es für dieses Verhalten des Vectors irgendeine Rationale begründung??

 

[0xdeadbeef]

Ist das "oout.writeObject(msg);" bereits das Verschicken der Nachricht?

Falls erstmal ein Cache vollgeschrieben wird, ist das geschilderte Verhalten plausibel. Dann braucht's halt sowas wie ein Flush.

 

[Icewind]

hm ja das oout.writeObject(msg); ist das verschicken der nachricht...

aber was hat das damit zu tun??

 

[akira]

Tja das Problem daran war nur das immer das gleiche beim anderen Client ankam (es wurde allerdings die
richtige Anzahl an bytes übertragen), also baute ich ein das er mir immer einen Teil des Lesearrays ausgibt.
Tja da steht auch ,wie nicht anders zu erwarten, immer was anderes drinn. Allerdings würde bei dem letzten
Datensatz auch etwas anderes übertragen, und der war ja nicht in der Leseschleife enthalten.

Wie meinen? :autsch:

Was macht der Vector nicht wie er soll?

 

[0xdeadbeef]

Wie gesagt: man müßte mal klären, ob die Nachricht dann wirklich sofort verschickt wird, oder ob die Nachrichten gepuffert und dann zusammen verschickt werden. Im letzteren Fall wird das Byte-Array ja dauernd überschrieben und alle Nachrichten enthalten dieselben Informationen, was ja auch klar ist, weil es nur ein Byte-Array gibt.
Das ist dann aber kein Fehlverhalten des Vectors, sondern es fehlt halt das Flush bzw. das Design entspricht nicht den Erfordernissen.

 

[Icewind]

ok das kann sein...
tja sowas muss man wissen...

hm in der api ist bei inputStream und FileInputStream nie die rede von einem buffer und eine flush methode gibts es auch nicht.... naja ...

 

[0xdeadbeef]

Und da wird auch sicher kein BufferedXxputStream benutzt?

 

[Icewind]

... hab beim falschen Stream nachgeschaut... naja der ObjectxxputStream verwendet einen buffer...
ok nun is mir das klar danke :wink: