On Monday 05 of December 2005 22:08, jeeff wrote: > Ahojte, > > 5 minut na HTTP poziadavku je nic. Predstavte si stahovanie 1GB suboru > cez HTTP, tiez to bezne trva viac ako 5 minut. Finta totiz nie je v > dlzke poziadavky, ale v dlzke neposielania dat. Takze staci, aby server > generoval nejake data. > > Uspesne pouzivame pri importe / exporte dlhych dat nasledovny postup: > > Server ma vyexportovat Excel s nejakym zlozitym reportom. > 1. Klient posle poziadavku, tu spracovava servlet. > 2. Servlet prve co spravi je to, ze vygeneruje response, cize zasle kus > HTML kodu (hlavicka, styly... odporucam ten HTML kod dat do JSP a v > servlete spravit pageContext.include(), da sa to potom lahsie modifikovat) > 3. Pocas generovania musi na klienta nieco posielat > 4. Po vygenerovani do vystupu posle HTML kod s linkou na subor a ukonci > response > > V bode 3 kedze sa musi nieco generovat, tak mame napisanu komponentu v > JavaScripte, ktora aktualizuje progress bar (podmienkou je, ze musime > vediet odhadnu, kolko % uz mame hotove). Takze v bode 3 posielame na > klienta nieco ako: > ... kopa prazdnych medzier, aby IE necachoval (aj ked sa pouzije > out.flush, nepomoze) tak aspon 500 znakov ... > <script...>updateProgressBar(30);</script> > ... kopa prazdnych medzier... > > Pre klienta je to super, netreba na serveri riesit MQ (aj ked vyhoda MQ > je v seriovom spracovani, takyto nas postup by mohol sposobit DOS, ak by > to spravilo vela pouzivatelov naraz) a naviac klient vidi kolko % uz ma > hotovych (do progress baru sa da dorobit aj straveny cas, aj odhadovany > cas do konca). > > Taketo riesenie pouzivame casto s dobrymi vysledkami a zatial nebol > problem v tom, ze by prehliadac zatvoril spojenie a teda pouzivatel by > nevidel koniec procesu. Naviac to vyzera dost efektne a okno sa > nerefreshuje, takze je to kontinualny proces.
Bojim se, ze tento pristup bych pouzil bud pred deseti lety nebo ve chvili, kdy mam k dispozici jenom links/lynx/wget. To, co potrebuje tazatel, je plne standardizovane asynchronni (idealne reliable) komunikace s moznosti zjisteni stavu zpracovani. Takze bud nejake JMSko nebo asynchronni SOAP stack podporujici callbacky. Samozrejme ze otazkou je, jestli klientem je prohlizec bez Javy nebo nejaka aplikace/aplet, ktera si muze ten callback vytvorit. Pokud neni na klientovi Java, tak v klidu spustit thread na serveru, ulozit si do sessny nejake IDcko a generovat linky, ktere obshauji toto idcko pro provazani s aktualnim stavem processing onoho dlouho trvajiciho pozadavku. Na sevreru je mozne krome threadu pouzit MessageBeanu, ktera je sama o sobe emulaci Threadu v J2EE svete. Je-li navic transakcni, je vsechno v poradku... -- Oto 'tapik' Buchta, [EMAIL PROTECTED] Senior Engineer, Systinet Corp, http://www.systinet.com
