Preji hezde rano, 2008/3/14 Jozef Babjak <[EMAIL PROTECTED]>: > > > ^-- To je velmi jednoduche: lebo tie udaje potrebujem. :-) > > > > > > Presnejsie: citam zo siete stream, konkretne odpoved HTTP servera, > > > ak by na tom zalezalo. Tato odpoved moze mat niekolko desiatok bajtov, > > > ale kludne moze mat 10MB. Takze nemozem dopredu vediet, aky velky > > > buffer bude dostatocny na nacitanie udajov. Preto citam udaje po > castiach > > > s velkostou CHUNK a tieto casti si odkladam (kazdu ulozim do > BasicContent, > > > a tieto objekty skladam do AggregatedContent); citanie ukoncim, ak sa > > > nacita prvy "neplny" buffer. > > > > To chapu, ale ten buffer muzete samozrejme "recyklovat", InputStream > > vam do nej nakopiruje data ze vstupu a je mu jedno ze tam predtim > > nejaka data byla. > > Jediny problem by byl pokud by konstruktor new BasicContent(buffer, > > bytesRead) predany buffer sebere pro sebe, coz nepredpokladam (bylo by > > to velmi nestandardni reseni). > > ^-- Ano, BasicContent si ten buffer necha pre seba, ano, bez toho, aby > si urobil defenzivnu kopiu. Co sa vam vidi nestandardne na tom, ze nechcem > v programe kopirovat potencialne obrovske mnozstvo udajov len preto, > aby som mohol InputStreamu davat opakovane ten isty buffer na citanie?
Nic, jen to ze je te z meho pohledu nestandartni chovani, t j nesektal jsem se s tim, vzdy slo buffer recykluvat, hlavne proto ze jsem ho vetsinou predaval nejake metode write() Jestlize toto je vami zamyslene chovani pak to je samozrejme spravne, jen bych na to na vasem miste upozornil vase kolegy abyste je nezmatl tak jako mne :-) > > > > > > > 3.B) Nacitalo sa menej ako CHUNK bajtov; patrne sa docitalo do > konca > > > > > streamu a teda dalej citat nemusim. > > > > > > > > Obavam se ze zde je chyba - v javadocu jsem nenasel zminku ze musi > > > > nacist presne tolik byte jako je delka bufferu, je tam zminka ze > nacte > > > > alespon 1 byte. > > > > Je to sice na prvni pohled nelogicke (proc by to delal?), ale asi to > > > > muze zpusobovat vas problem. > > > > > > ^-- Ako konkretne to ma sposobovat moj problem? Stale nerozumiem. > > > > > No, obavam se ze InputStream vam nakopirovava do daneho bufferu > > vetsinou tolik byte jako je delka bufferu, ale obcas se rozhodne tam > > nakopirovat min, i kdyz ma dalsi data k dispozici. > > ^-- Ano, presne tomu zodpoveda aj moje pozorovanie, ale to som uz > predsa napisal v povodnom maili. Moja otazka ale je, ze preco je tomu > tak, ked javadoc tvrdi, ze: > > > > "This method blocks until input data is available, end of file is detected, > or an exception is thrown." > No, rek bych ze tomu tak je protoze tomu tak muze byt - v tom javadocu nikde nemate napsano ze musi naplnit ten buffer cely (pokud ma jeste nejaka data), tutiz je na implementaci kolik toho do bufferu nakopiruje. Viz javadoc: "Reads some number of bytes from the input stream and stores them into the buffer array b." Moje domnenka je takova ze vas InputStream vraci data (metodou read() ) "po radcich" nebo "po bufferech" (co je mensi), protoze je to z hlediska jeho implementace jednodussi (cte z http ktery je obecne "radkovy"). Z tohoto bohuzel vyplyva ze v pripade ze pokazde alokujete novy buffer pro metodu read(), ktery pote uschovavate v instanci BasicContent tak budete mit nenulove mnozstvi "neuplne zaplnenych" bufferu a budete zbytecne zabirat misto v pameti.... S pozdravem, Jindrich Vimr -- Jindrich Vimr <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> http://www.jesta.net Nyranska 46, 323 00 Plzen, Czech Republic GSM: +420 604 711 457
