Názory k článku
Síťování v Javě: Úvod

Zajimavy pristup, pouzit vice vlaken. Proc to delat jednoduse, ze ;-))

Copak se v Jave neda pouzit neco na zpusob syscallu select(2)? Tzn. funkce/trida ktere predam pole streamu ze kterych chci cist (stdin, net) a ona bude cekat az do doby nez jeden z tech streamu ma k dispozici data. Pak mi rekne ktery to byl a ja muzu vesele pokracovat. To je, rekl bych, mnohem jednodussi a standardnejsi pristup nez machrovani s threadama...

Co máte proti threadům? Za pár let budou PC s jednojádrovým CPU (jedním CPU) patřit do muzea a přitom se v podobných článcích stále "učí", že thready snižují výkon. Opravdu to má autor odzkoušené a potvrzené na víceprocesorovém stroji?

Jednak je rozdil mit thready dva nebo jich mit dva tisice, kdyz mate tisic spojeni.

A potom, nejde ani tak o rychlost, jako o jednoduchost kodu (s thready musite davat bacha, co musi byt synchronized atp.).

Jednak je rozdil mit thready dva nebo jich mit dva tisice, kdyz mate tisic spojeni.

Tak to je určitě rozdíl.

A potom, nejde ani tak o rychlost, jako o jednoduchost kodu (s thready musite davat bacha, co musi byt synchronized atp.)

To bych ani neřekl. Přece jen se každý thread stará o své vlastní spojení a s ostatními "spojovacími" vlákny nemá důvod komunikovat. Jediné, co je nutné synchornizovat (ale to vždycky), jsou objekty společné všem vláknům. Psal jsem (přiznávám, jednoduchý) komunikační program pro LAN (v C#) a pro každého uživatele, kterého jste měl v seznamu, běžel jeden thread, který zjisťoval jeho stav (tj. to vlákno bylo skoro pořád ve stavu sleep) + další vlákna pro otevřená okna, kde jste si chatoval s tím daným uživatelem. Rozdělení do threadů bylo velmi jednoduché a přineslo daleko větší možnosti. Max počet vláken toho programu co jsem zkoušel byl 60, což není vůbec moc.

Dovolil bych si podotknout, ze pokud v Jave pouzivate GUI - a urcite i v jinych pripadech (zalezi na implementaci dotycne oblasti) - tak Vase aplikace JE vicevlaknova, aniz byste se toho jako aplikacni programator ucastnil... Takze hrani si na pidimetry vykonu pres Select/Poll aniz bych znal technologii mi prijde usmevne...:-)

Ale ono je to tak správně. Tento přístup (neblokující) se v praxi samozřejmě využívá s několika vlákny, nejen s jedním. Jejich počet je ale výrazně nižší (např. roven násobku počtu procesorů - 4, 8 a podobně). Dost dobře nechápu Tvůj komentář. Jinak ale přístup s více vlákny zde bude pořád - někde se třeba hodí lépe.

Dost dobře nechápu Tvůj komentář.

Pouze mě zaráží, že se "tolik" píše proti použití vlákna na každé spojení. Nic víc nic míň.

I procesory x86 udělali hodně velký pokrok, co se týče zpracování mnoha procesů (např. rychlejší přepínání kontextu, masivní paralelismus uvnitř CPU -- na GPU to ještě nemá, ale snad časem, "inteligetní" prefetch do cache). A bude se to zlepšovat. Budou přibývat jádra, zvětšovat se cache, měnit se celá architektura PC (AMD například používá NUMA ve svých multiprocesorových řešeních, místo "klasického" SMP na FSB jak má Intel). Tak nevidím důvod, proč nemít v programu třeba 512 vláken. Možná se mýlím a rád se nechám poučit.

Treba rozlisovat medzi Threadmi na klientovi a v servri. Na servri treba setrit pretoze uz iba kontext switching medzi 1000 threadmi ti zozerie dost velku cast CPU.
Na servri je pouzitie select() nevyhnutnostou. Specialne co sa tyka triedy java.net.Socket ma problem ze za urcitych okolnosti nie je mozne rozlisit ze socket bol z druhej strany zatvoreny (programovo alebo z dovodu sietovej chyby) takze takto napisany server po case lahne.
Nadmerna zataz (sietova,...) zlozi akykolvek server. V dobrom servri ktory ma byt odolny aj proti DoS utoku musis mat dobre vyriesene fronty, cakacie stavy a aj odmietanie poziadaviek.

V baliku NIO samozrejme select() je a i ostatni veci tady funguji na podobnem principu, jako v "C-cku".
S temi vlakny je spis problem ten, ze pokud bude tech komunikaci vice, pak nam vlakna budou narustat a narustat.

Druha vec je ta, ze uvedeny kod se netyka Telnet klienta, ale TCP trubky. Telnet zpracovava signaly typu Ctrl-C, Ctrl-Z a podobne veci, ktere by zarizeni typu TTY melo umet.

Použití více vláken je právě ten jednodušší přístup. Nesrovnatelně jednodušší - odpadá nutnost stavového automatu. V C se tradičně spíše používá fork(), ale princip je úplně stejný.

Samozřejmě, slabinou tohoto způsobu je špatná škálovatelnost.

Takze misto 'machrovani s Threadama' (= dvakrat pouziti stejne jednoduchoucke tridy) nasadime nejake podminky/pomocne struktury na rozhodovani kam se ma zapisovat, zacneme resit problemy se zablokovanim vystupu a tim padem zablokovanim obsluzneho vlakna atd? Tomu se ted rika jednoduchost?:)

Vzhledem k tomu, ze melo jit o jednoduchou ukazku prace se siti, tak je to imho v pohode, az budete mit server obsluhujici tisic spojeni najednou, tak jsou selecty na miste. A co se standardnosti tyce, tezko rict, ale co jsem videl, tak mi prijde, ze se tenhle pristup opravdu hodne pouziva, prace s vlakny je v Jave jednoducha a dokud jich staci par...

napr. taky BeOS bol napisany ako masivne threadovy system a bola s nim radost pracovat. Takze threadov by som sa az tak nebal.

Tak za takovýhle kód bych vraždil. Pokud uzavírám stream, socket, a já nevím co všechno ještě, vždycky ve finnaly bloku. Možná budete namítat, že tohle je jen "ukázkový zdroják", ale pak k vám přijde do týmu nějaký ucho, co se učí z článků na internetu a dělá takovýhle prasárny a diví se, že má stovky neuzavřených connection třeba na databázi.

Ještě jsem zapoměl dodat, že close() by se nemělo volat "pro jistotu", ale vždycky a to i nad Input/Output streamem.

Tak tak, ony se vám třeba data do souboru pak ani nezapíšou, a vy ladíte, a ladíte... :-D

Asi tak, další dobrá věc kterou není radno opomíjet je flush() :)
Shodou náhod zrovna psal někdo na builder.cz, že má ORA-01000 musel jsem se začít smát :D

A chyby by se měli psát do System.err, ne do System.out.

A to jako proc? Protoze si to tak nekdo pred 30-ti lety rekl? Stream jako stream, jediny jeho atribut je, zda-li je vstupni, vystupni nebo pro jistotu oboji...:) (ano i takove Stremy existuji a jsou implementovane)

Třeba proto, že System.err se pak dá snadno odchytit (2&>) a uložit do logu a tím pádem oddělit od obyčejných informací vypsaných do System.out.

Nepochopil jste... ja se ptam, proc zrovna stream s FD 2, proc ne treba 8... to, co popisujete se tyka neceho jineho a sice (dle Vas nemoznosti) demultiplexovat data z jednoho streamu... (i to je kupodivu jednoduse mozne)

> demultiplexovat data z jednoho streamu... (i to je kupodivu jednoduse mozne)

Poradíte?

Very simple - treba grep?

Ano, proc to delat jednoduse, kdyz to jde slozite, ze...

Jasne proc milionkrat implementovat kolo se vsema ficurama, kdyz to jde udelat jednou a pak to jako komponentni system vyuzit...:-r

??? stderr je vsude (i ve Widlich, na rozdil od grepu), ten netreba implementovat vubec

Aha a kristalovou kouli abyste vedel, co zada obsluha a kam to chce smerovat fasujete pri nastupu na smenu...?

?

Po přečtení následujících komentářů je mi jasné, že s vámi je zbytečné se bavit, ale dneska mám dobrou náladu.

Takže, představme si výstup na konsoli z nějakého prográmku na zpracování speciálních obrázků:

$imageprocess: -i image.bin -offt image.fft -ostats image.stats
Processing Image
[Warning] Image file is in deprecated format, version 0.5.
[Warning] Image does not contain statistical information.
Starting Fast Fourier Transformation...
[Warning] Image size is not compatible with FFT, cropping image.
Done
Gathering Statistical Information...
Done
image.fft Saved
image.stats Saved

Takhle by to vypadalo po vypisu všeho do System.out. A to jsem vzal ještě mírnější versi, kde nenastaly ty "velké chyby", kterých může být klidně přes sto. Uživatel ví, že obrázek není čtvercový a že se bude ořezávat, uživatel ví, že v obrázku staré verse nejsou statistické informace. Proto preferuje výpis:

$imageprocess: -i image.bin -offt image.fft -ostats image.stats 2&>/dev/null
Processing Image
Starting Fast Fourier Transformation...
Done
Gathering Statistical Information...
Done
image.fft Saved
image.stats Saved

Zdá se mi to přehlednější, vám ne? A ten váš very simple grep není všude a ne každý s ním umí pracovat. Přesměrovnání do souboru ano.

no, a kdyz uz delat kejkle s logovanim, co treba neco jako log4j?

Suhlas. Tiez myslim, ze ked uz sa uvazuje rozdeleni vypisov podla ucelu, je namieste pouzit niektori logovaci system - najcastejsie log4j alebo priamo API v JDK 1.4 a vyssie.

Tedy přece nejde o žádné sofistikované logování. Jde o prosté vypsání chybových hlášení. U takto jedoduchého programu by myslím bylo zavedení nějakého speciálního logování spíše na škodu.
Tak jak tak, chybové hlášení patří na standardní chybový výstup. Na tom trvám.

A ja pro zmenu trvam, ze chybove hlasky patri tam, kam je ocekava obsluha, aby na ne mohla aktivne a adekvatne reagovat... coz je treba remote konzola, nejake sofistikovane zarizeni, soubor atd... - to, ze lze zajistit presmerovani FD 2 na jine (s omezenimi) je z historickych duvodu a neodpovida soucasnym potrebam... - log4j je dobry priklad, jak to resit... To, ze Cckari tuto vymozenost bezne neznaji, jednoduse proto, ze GLIBC nic takoveho neobsahuje, neznamena, ze tato potreba neni i zde... - treba ovladani technologickych procesu (jichz jsem se ucastnil) bylo sice implementovano v C, ale jiz pred 15 lety byly potreby naprosto shodne s tim, co umoznuje log4j... - (log4c neexistovalo) takze opakuji - stderr je hezky, historicky, ale neodpovida casto potrebam... zejmena pokud potrebujete dalsi veci - muzete mi rici, jak FD 2 "presmerujete" do Event loggeru ve Win32 platforme?

Grep je dobry ked vies co hladas. Ty ovladas napr. vsetky chybove hlasky Apacha (aj s pluginmi)?
Samozrejme ze chyby patria do file descriptora 2 aby sa dali oddelit alebo do samostatneho error kanala v logovacom baliku.

Ano, pretoze su to zauzivana standardy a este aj dnes velmi pouzivane. Preco prepinanie medzi oknami niekto nezmeni v kazdej novej verzii Windows. Preco F1 je help... to su zauzivane standardy a o potrebe oddelenia chyboveho a standardneho vystupu sa nebudeme bavit.

No - ono je "trosku" rozdil mezi zauzivanymi zvyklostmi (F1) a prostredky urcenemu k necemu (stderr). Nebo ne?

... z hlediska navrhu by me spis zajimalo, co tam dela ta dedicnost??

Ad close() - namet na flame ;) : tady to neni az tak moc videt, ale k cemu je mi pak cely ten system s garbage collectorem, kdyz se o lifetime objektu (coz v tomto pripade defakto close je) musim starat sam? To sme pak nekde zpatky pred 20ti lety na strukturovanem programovani :-/

K tomu close:

1) Socket (nebo file handle) je zdroj operačního systému a garbage collector se ho tedy bohužel netýká.

2) Patřičné konkrétní třídy samozřejmě mají metodu finalize(), ve které se close() volá.

Jenže nikde neni garantováno, že se finalize() opravdu zavolá, takže na to bych se moc nespoléhal

close() není o lifetime objektu. Vy close() dokonce ani nemusíte volat, pokud zavoláte flush() a o data nepřijdete. To nemá s garbage collectorem nic společného. Jak by měl garbage collector vědět, které popisovače souborů ještě potřebujete a které už ne?

V případě soketů se při ukončení JVM ten socket zavře, ale obecně je to pěkně fuj. Vezměte si například spojení na databázi, kde je to "obdobné", jenže než se GC dostanek tomu, aby ty objekty zlikvidoval, tak vám ty spojení dojdou. Nehledě na to, že se ve větších aplikacích používá ConnectionPooling, takže reference na Connection stále je, ale vy ji neuzavřete, takže si tam prostě visí dokud nedojdou spojení.

Chytrejsi ConnectionPooly si tohle hlidaji a za osklive chovani pekne vynadaji;).

Aha, takze kdyz chci udelat jednoduche IP spojeni, pak musim pouzit connection pool, protoze jiny pristup v Jave je riskantni. Neni to nahodou "trochu" narocne na systemove prostredky?
Jiste, Java neni na kdejakou utilitku, je to "nastroj" pro velke masiny, kde je (casto) vykonu na rozdaj. Trebaaaaa - hm, treba mobil! :-D
PS: V Jave ani Basicu nekoduju, protoze jsem si zvykl delat design v jistem smyslu objektovy. Neberte to jako osobni utok, jen se strasne bavim na ucet <no flame please> tech cvoku co Javu vymysleli a tech, co si mysli, ze je to v poradku. </no flame please>

My se bavíme také :-) Tohle se opravdu jako seriózní flame brát nedá.

Vlakna jsou fajn, uz jsem je nekolikrate pouzil, vzdy to prisli tak nejak jako
blesk z nebe, problem bude, ze a ted nechci soudit, jim tady stejne nikdo
poradne nerozumi, vcetne me. Bez urazky.
Proti selectu(poolu) taky nemam nic, kdyz je dobre pouzit je tez fajn.
pochopitelne vyuzivat stderr, o tom zadna. stejne jako uvolnovat spojeni,
to vi kazdy, flush() je super bez diskuze, klasicky duraz na cem bazirujou na
skole, kontrola navratovych hodnot a to i u takoveho close() !

Osobne nemam rad Javu, proto bijte ji dokud nezdechne. Jen zertuji,
sitove programovani v Jave je stejne useless, ping v ni nenapisete, tak
cemu to. Enjoy JDBC(silene rozhrani). bytecode is useless.

42. A co slysi webmaster ve vlaku? TD TD TD, http://hovnocucy.predseda.com/; init 0

- Ak nerozumies threadom tak si to dostuduj. Ja si myslim ze im rozumiem dost dobre.
- Multithreading v klientskych aplikaciach nie je problem. 2-6 threadov je absolutne v pohode. Na problemy na dnesnom zeleze narazite tak pri 80-140 threadoch. Threadmi treba setrit v server aplikaciach.
- NIO a select v jave ma jeden vedlajsi problem. Suvisi to z blokovacimi readmi a serializaciou.
- close() je bez diskusie ale musi byt vhodne pouzite. Tiez to nie je celkom logicke. Ucebnicovy priklad:
FileInputStream fInput=new FileInputStream("aa.txt");
try {
  fInput.....
} catch (Exception ex) {
  ex.printStackTrace();
} finally {
  fInput.close();
}

Kedze ale aj new FileInputStream moze vyhodit FileNotFoundException tak najlepsie to bude vyzerat asi takto:
FileInputStream fInput=null;
try {
  fInput=new FileInputStream("aa.txt");
  fInput.....
} catch (Exception ex) {
  ex.printStackTrace();
} finally {
  if (fInput != null) {
    fInput.close();
  }
}

- A na zaver aj odkaz pre ostatnych: "Na javu mi nesahajte".

"2-6 threadov je absolutne v pohode"
:-D Aha, tak to jo. To jo. To je v pohode. :-DDD

A ty si co za vesela kopa. Dva prispevky nad tebou sa chlapi bavia ze naco 2 thready. Ze to je zbytocna zataz. Len som na to reagoval nejakym vysvetlenim.

Dyd jo, v poradku. Jen me dorazilo, jak to vypada: 2 thready jsou OK. No, aby nebyly! Cekal bych neco jako "20 thready je ok" nebo lepe "200 threadyu je ok". Nic proti, to jen tak na vysvetlenou. Treba tvuj prispevek z "Dnes 1:20" by se mel tesat do kamene. Tak to jen tak na vysvetlenou.
Ano, vesela kopa jsem, protoze je patek a bavime se o Jave. To nejde prezit jinak nez s usmevem.
Hezky den. :-)

Fajn, zpatky k tematu ke close(), neucebnicovy, avsak realnejsi priklad:

try {
fout = new FileOutputStream("aa.txt");
log1 = SomeLogger.createUsingStream(fout);
log2 = SomeLogger.createUsingStream(fout);
create more objects using fout, log1, log2
}
catch (whatever) {
}
finally {
fout.close();
throw FailedInitialization();
}

... some stuff, use created objects in threads, ...

A kdo ted zavola close() na fout? Tohle vyresil napr. COM uz pred 15-20ti lety ;)

Prepac nerozumiem. fout.close() sa predsa zavola vzdy pri opustani try/catch bloku. Este ti tam moze nastat NullPointerException ked subor "aa.txt" neexistuje pretoze fout bude null a volanie close() odpali NPE.

Oops, chyba. Ten fout.close() tam mel byt pouze v pripade exceptiony (a to jeste s otaznikem).

V principu jde o to, ze ten fout je sdileny vice entitami a neexistuje (nechce existovat) nekdo, kdo rekne, ze fout se muze zavrit, protoze uz ho nikdo nepouziva.

Nahodou, bytecode se celkem uspesne pouzival v osmibitovych pocitacich pro interpretaci basicu. :-D
Ale vazne - moooc hezky jsi to napsal, Palo asi moc nepochopil, kde je zakopany hafak.

ahoj, vedel by nekdo jakym zpusobem podobne spojeni uskutecnit pres SSH?

Ak pouzijem blok finally
...
finally {
os.close();
}
...

tak pri preklade mi to hadze chybu:

Telnet.java:108: unreported exception java.io.IOException; must be caught or declared to be thrown
os.close();
^
1 error

Som lama, poradte ;)

Peter

finally
{
if (os != null)
try {os.close();} catch (Exception e){}
}

Jen jazykový detail. "Neznámý host" ... to je přece česky blbost. Anglicky host není to samé jako česky host.