Dakujem obom za poznamky k riadeniu flow tej metody; obavam sa ale, ze moj
problem neriesia. IMHO jedina "chyba" v tom flow je zbytocne 'else',
kedze 'if' vetva
konci prikazom 'break'.
> me se nejak nelibi ten cyklus, vetsinou ho pisu takhle:
> -----------------------------
> while( ( bytesRead = in.read(buffer) ) > 0 ){
^-- Postfixny cyklus je pouzity preto, lebo v kazdej iteracii
potrebujem naalokovat novy buffer.
> ( vo tom vasem se mi nejak nelibi to while (bytesRead == CHUNK); )
^-- Logika toho cyklu je zalozena na tom, ze read(byte[]) moze v
principe skoncit tromi sposobmi:
1) Vyhodi vynimku; k tomu v tomto pripade nedojde.
2) Dosiahol sa end-of-stream a vrati -1; osetrene break-om; cuduj sa
svete, ani k tomuto nikdy nedojde.
3) Nacita up to CHUNK bajtov, umiestni ich do pola buffer a vrati
hodnotu, kolko nacitala, pricom BLOKUJE
pri nedostupnosti dalsich udajov, takze to, ze udaje prichadzaju po
castiach, de facto nemusim riesit. V tomto
pripade mam 2 moznosti, ako zareagovat:
3.A) Nacitalo sa prave CHUNK bajtov, t.j. cele pole; pole niekam
ulozim (do BasicContent, ktory ulozim do
AggregatedContent) a musim citat dalej (do noveho bufferu v dalsej
iteracii), lebo sa patrne este neprecital cely stream.
3.B) Nacitalo sa menej ako CHUNK bajtov; patrne sa docitalo do konca
streamu a teda dalej citat nemusim.
Chyba je -- podla mojich pokusov -- v tomto bode 3.B. Zmena zaverecnej
podmienky cyklu na
while(bytesRead >= 0);
alebo kludne na
while(true);
sposobi, ze slucka sa zopakuje aj po prvom "neuplnom" nacitani bufferu
(t.j. readBytes < CHUNK) este raz
a program zostane visiet vo volani in.read(); cakal by som, ze volanie
read() vrati okamzite -1.
No a tu vidim rozpor: Ak bol stream docitany do konca, read() ma
vratit -1, nie sa blokovat. Ak ale nebol docitany
do konca, preco sa read() neblokoval pri "predchadzajucom" volani a
nedocital buffer doplna, az po CHUNK?
> Pripadne obalit vstupni stream BufferedOutputStreamem......
BufferedInputStreamom patrne. Vyskusam.
J.
