Re: java.lang.OutOfMemoryError: unable to create new native thread
-Xss znamená velikost zásobníku pro každý thread, pokud jej příliš snížíte, tak riskujete SctackOverflowException, pokud tento parametr zvednete, tak omezíte maximální počet threadu, které jste schopen využít. V mém případě, kdy je maximální počet spuštěných threadů cca 40 je to jedno, jelikož snižování velikosti Xss má význam až od tisíců thready v rámci jedné JVM. Mne by nepřekvapilo, kdyby aplikace spadla na OutOfMemory z nedostatku heap, ale zrovna v případě procesů to prostě nechápu. Jaroslav Hurdes Dne 13.4.2012 9:00, arsi napsal(a): Hi, Treba nastavit -Xsssizeset java thread stack size Nema v zasobniku pre thready dost miesta... Arsi On 04/13/2012 07:12 AM, kek forums wrote: Zdravím, - k tomu statickému snímku z JConsole by asi bylo dobré ještě zaslat snímek s grafy, kde bude vidět vývoj chování aplikace v čase, třeba tam je nějaký peak, který to položí na lopatky, protože tady z těch statistik to vypadá v pohodě. - nastavil bych tomu JVMku -/XX/:+HeapDumpOnOutOfMemoryError - a výsledný dump analyzoval nějakým nástrojem, jako http://www.eclipse.org/mat/ - jak již bylo napsáno - nevytvářel bych vlákna nekontrolovaně, ale raději bych volil nějaký ThreadPool, tak aby se počet vláken dal limitovat a navíc se zásadně snížila režie spojená s vytvářením vláken - např.: http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html - navyšování různých parametrů Xmx, Xms, Xss, permGen - je sice možné, ale dělám to vždy až potom, co detekuji v čem je problém - protože v 80% případů je problém v aplikaci a tato navýšení řeší následky, nikoliv příčinu problému, ale především často jen pád oddálí, ale nic neřeší :). Doporučoval bych nastudovat nějaké materiály kolem rozložení paměti, jako například http://avricot.com/blog/index.php?post/2010/05/03/Get-started-with-java-JVM-memory-(heap%2C-stack%2C-xss-xms-xmx-xmn...) http://avricot.com/blog/index.php?post/2010/05/03/Get-started-with-java-JVM-memory-%28heap%2C-stack%2C-xss-xms-xmx-xmn...%29 - pak člověk zjistí, že zvyšování HEAPu je naopak kotraproduktivní, protože Thread Stack se alokuje mimo tuto oblast. Takže naopak je lepší ten Xmx limit snížit, aby zbylo více na ta vlákna opět v souvislosti s XSS. Jinak tato oblast paměti je používána i pro JNI, GC, atd. Ale jak koukám, vaše XSS je pro peak 31 vláken asi taky v pohodě. - a když z toho všeho nic nepomůže - tak klasika - začít ořezávat aplikaci v testech a izolovat, kde je problém - tady bych udělal mock na to JNI - JNI vyhodil a zkusil, zda to pomůže - třeba si v rámci JNI alokujete nějaké velké množství paměti, které vám sebere prostor pro ta vlákna. Dne 13. dubna 2012 0:15 re...@centrum.cz mailto:re...@centrum.cz napsal(a): Ahoj, podle mě by mělo stačit zvednout -Xmx1024M třeba na Xmx2048m. Jinak 12 GB RAM je ti pro 32 bitovou javu k nicemu, neboť velikost heapu je omezena. A to se častečně liší podle systému. Radek * * __ Od: Jaroslav Hurdes j...@ataco.cz mailto:j...@ataco.cz Komu: konference@java.cz mailto:konference@java.cz Datum: 12.04.2012 22:35 Předmět: Re: java.lang.OutOfMemoryError: unable to create new native thread Systém má k dispozici 12 GB RAM. Využití paměti je na cca 33% CPU 20% Procesu cca 70, Threadu cca 5000 na cely OS, takže docela v pohodě. Jaroslav Hurdes Dne 12.4.2012 20:59, Peter Hanuliak napsal(a): skusali ste pozriet ako vyzeraju zdroje windows systemu? ako on vyzera s threadmi? pamatou a pod? 2012/4/12 Roman Pichlíkroman.pich...@gmail.com mailto:roman.pich...@gmail.com: hmm je uz to opravdu jenom strelba od boku, co zkusit nastavit PermSpace? 2012/4/12 Jaroslav Hurdesj...@ataco.cz mailto:j...@ataco.cz: Ne, tato třída nemá s JNI nic společného. Je to jednoduchý server, který na požádání vytvoří thread, obslouží požadavek a ukonči se. Tato třída má na svědomí ten celkový počet spuštěných threadu, které ale žijí jen velmi krátce (klient se zeptá na stav aplikace a po odeslání zprávy je thread ukončen). Jaroslav Hurdes Dne 12.4.2012 20:13, Roman Pichlík napsal(a): Vola se to JNI v ramci CommandClientsManager$Client.start? 2012/4/12 Jaroslav Hurdesj...@ataco.cz mailto:j...@ataco.cz: Vláken je spuštěno pouze 26, viz výpis z dokumentace k jconsole Threads Live threads: Current number of live daemon threads plus non-daemon threads Peak: Highest number of live threads since JVM started. Daemon threads: Current number of live daemon threads Total started: Total number of threads started since JVM started (including daemon, non-daemon, and terminated). DLL je volána přes JNI a nemělo by tam vzniknout souběžně více vláken
Re: java.lang.OutOfMemoryError: unable to create new native thread
Zdravim, Na vasem popisu situace me zaujalo max. 12GB pameti a 33%-ni vuziti (takze +- 4GB obsazene pameti). A ted moje silena domnenka: Java je pouze 32bit proces, tudiz dal nez za 4GB nevidi a pamet pro stack se alokuje mimo heapu (a samozrejme i mimo permgen). Myslim si, ze pro javu se v tech jejich ctyrech gigabajtech uz nenajde misto pro novy stack pro nove vlakno (muze tam byt os, dalsi programy, ...) a tak skonci s OOM, idkyz je vlastne 66% pameti nevyuzite. Jestli to ale skutecne tak muze byt, si nejsem jisty. Hodne zdaru, :J On Thursday, April 12, 2012, Jaroslav Hurdes wrote: Systém má k dispozici 12 GB RAM. Využití paměti je na cca 33% CPU 20% Procesu cca 70, Threadu cca 5000 na cely OS, takže docela v pohodě. Jaroslav Hurdes Dne 12.4.2012 20:59, Peter Hanuliak napsal(a): skusali ste pozriet ako vyzeraju zdroje windows systemu? ako on vyzera s threadmi? pamatou a pod? 2012/4/12 Roman Pichlíkroman.pich...@gmail.com: hmm je uz to opravdu jenom strelba od boku, co zkusit nastavit PermSpace? 2012/4/12 Jaroslav Hurdesj...@ataco.cz: Ne, tato třída nemá s JNI nic společného. Je to jednoduchý server, který na požádání vytvoří thread, obslouží požadavek a ukonči se. Tato třída má na svědomí ten celkový počet spuštěných threadu, které ale žijí jen velmi krátce (klient se zeptá na stav aplikace a po odeslání zprávy je thread ukončen). Jaroslav Hurdes Dne 12.4.2012 20:13, Roman Pichlík napsal(a): Vola se to JNI v ramci CommandClientsManager$Client.**start? 2012/4/12 Jaroslav Hurdesj...@ataco.cz: Vláken je spuštěno pouze 26, viz výpis z dokumentace k jconsole Threads Live threads: Current number of live daemon threads plus non-daemon threads Peak: Highest number of live threads since JVM started. Daemon threads: Current number of live daemon threads Total started: Total number of threads started since JVM started (including daemon, non-daemon, and terminated). DLL je volána přes JNI a nemělo by tam vzniknout souběžně více vláken (získávání obrazu z frame grabberu). Jaroslav Hurdes Dne 12.4.2012 19:26, Roman Pichlík napsal(a): To je pocet celkove vytvorenych vlaken po dobu behu, nikoliv zivych, tech je tam relativne malo, 67 pokud dobre pocitam. 2012/4/12 Martin Caslavskymartin-l...@geek.cz: Máte 2.500 vláken a další už nejde vytvořit... První odkaz v Google popisuje tenhle problém: http://stackoverflow.com/**questions/763579/how-many-** threads-can-a-java-vm-supporthttp://stackoverflow.com/questions/763579/how-many-threads-can-a-java-vm-support Martin Caslavsky On 12 April 2012 18:08, Jaroslav Hurdesj...@ataco.czwrote: Zdravím, bojuji s vyjímkou, která nastává v mé aplikaci a nedaří se mi objevit příčinu. Vyjímka je následující: Exception in thread Thread-6 java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.**java:640) at cz.nitta.licenceplate.server.**business.communicator.** CommandClientsManager$Client.**start(CommandClientsManager.**java:357) at cz.nitta.licenceplate.server.**business.communicator.** CommandClientsManager.**addClient(**CommandClientsManager.java:**118) at cz.nitta.licenceplate.server.**business.communicator.** ClientsGatekeeper.addClient(**ClientsGatekeeper.java:196) at cz.nitta.licenceplate.server.**business.communicator.**ClientsGatekeeper.* *acceptClient(**ClientsGatekeeper.java:140) at cz.nitta.licenceplate.server.**business.communicator.** ClientsGatekeeper.run(**ClientsGatekeeper.java:213) at java.lang.Thread.run(Thread.**java:662) Prostředí je popsáno níže. V příloze je obrazovka z jconsole, kde je zobrazen počet threadu i stav paměti. Nesetkal se někdo s něčím podobným a nenašel řešení? Zkouším laborovat s různými parametry, ale zatím nic. 32 bit javu používám z důvodu nutnosti použít 32 bit dll. Díky. Jaroslav Hurdes OS Windows 7, x64 Verze javy (32 bit) java version 1.6.0_31 Java(TM) SE Runtime Environment (build 1.6.0_31-b05) Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) spouštění aplikace: java -XX:ThreadStackSize=256 -Xss256k -XX:ReservedCodeCacheSize=64m -Dcom.sun.management.jmxremote -Dcom.sun.management.**jmxremote.port=9001 -Dcom.sun.management.**jmxremote.authenticate=false -Dcom.sun.management.**jmxremote.ssl=false -server -Xcheck:jni -Xmx1024M -Djava.library.path=..\common\**lib\native -jar nitta-lp-rec-srv.jar ./cfg %* -- S pozdravem Roman Dagi Pichlik /* http://dagblog.cz/ -- :J
Re: java.lang.OutOfMemoryError: unable to create new native thread
Ahoj, ano, 32bit java nenaadresuje viac ako 4G. Ja som ale pochopil, ze sa k tomuto limitu jvm este nepriblizila, alebo ano? Co je vidiet v process table ( alebo ako sa to na windows nazyva )? -- Dusan Dňa 13. apríla 2012 11:03, Jiří Zůna j...@zunovi.cz napísal/a: Zdravim, Na vasem popisu situace me zaujalo max. 12GB pameti a 33%-ni vuziti (takze +- 4GB obsazene pameti). A ted moje silena domnenka: Java je pouze 32bit proces, tudiz dal nez za 4GB nevidi a pamet pro stack se alokuje mimo heapu (a samozrejme i mimo permgen). Myslim si, ze pro javu se v tech jejich ctyrech gigabajtech uz nenajde misto pro novy stack pro nove vlakno (muze tam byt os, dalsi programy, ...) a tak skonci s OOM, idkyz je vlastne 66% pameti nevyuzite. Jestli to ale skutecne tak muze byt, si nejsem jisty. Hodne zdaru, :J On Thursday, April 12, 2012, Jaroslav Hurdes wrote: Systém má k dispozici 12 GB RAM. Využití paměti je na cca 33% CPU 20% Procesu cca 70, Threadu cca 5000 na cely OS, takže docela v pohodě. Jaroslav Hurdes Dne 12.4.2012 20:59, Peter Hanuliak napsal(a): skusali ste pozriet ako vyzeraju zdroje windows systemu? ako on vyzera s threadmi? pamatou a pod? 2012/4/12 Roman Pichlíkroman.pich...@gmail.com: hmm je uz to opravdu jenom strelba od boku, co zkusit nastavit PermSpace? 2012/4/12 Jaroslav Hurdesj...@ataco.cz: Ne, tato třída nemá s JNI nic společného. Je to jednoduchý server, který na požádání vytvoří thread, obslouží požadavek a ukonči se. Tato třída má na svědomí ten celkový počet spuštěných threadu, které ale žijí jen velmi krátce (klient se zeptá na stav aplikace a po odeslání zprávy je thread ukončen). Jaroslav Hurdes Dne 12.4.2012 20:13, Roman Pichlík napsal(a): Vola se to JNI v ramci CommandClientsManager$Client.start? 2012/4/12 Jaroslav Hurdesj...@ataco.cz: Vláken je spuštěno pouze 26, viz výpis z dokumentace k jconsole Threads Live threads: Current number of live daemon threads plus non-daemon threads Peak: Highest number of live threads since JVM started. Daemon threads: Current number of live daemon threads Total started: Total number of threads started since JVM started (including daemon, non-daemon, and terminated). DLL je volána přes JNI a nemělo by tam vzniknout souběžně více vláken (získávání obrazu z frame grabberu). Jaroslav Hurdes Dne 12.4.2012 19:26, Roman Pichlík napsal(a): To je pocet celkove vytvorenych vlaken po dobu behu, nikoliv zivych, tech je tam relativne malo, 67 pokud dobre pocitam. 2012/4/12 Martin Caslavskymartin-l...@geek.cz: Máte 2.500 vláken a další už nejde vytvořit... První odkaz v Google popisuje tenhle problém: http://stackoverflow.com/questions/763579/how-many-threads-can-a-java-vm-support Martin Caslavsky On 12 April 2012 18:08, Jaroslav Hurdesj...@ataco.cz wrote: Zdravím, bojuji s vyjímkou, která nastává v mé aplikaci a nedaří se mi objevit příčinu. Vyjímka je následující: Exception in thread Thread-6 java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:640) at cz.nitta.licenceplate.server.business.communicator.CommandClientsManager$Client.start(CommandClientsManager.java:357) at cz.nitta.licenceplate.server.business.communicator.CommandClientsManager.addClient(CommandClientsManager.java:118) at cz.nitta.licenceplate.server.business.communicator.ClientsGatekeeper.addClient(ClientsGatekeeper.java:196) at cz.nitta.licenceplate.server.business.communicator.ClientsGatekeeper.acceptClient(ClientsGatekeeper.java:140) at cz.nitta.licenceplate.server.business.communicator.ClientsGatekeeper.run(ClientsGatekeeper.java:213) at java.lang.Thread.run(Thread.java:662) Prostředí je popsáno níže. V příloze je obrazovka z jconsole, kde je zobrazen počet threadu i stav paměti. Nesetkal se někdo s něčím podobným a nenašel řešení? Zkouším laborovat s různými parametry, ale zatím nic. 32 bit javu používám z důvodu nutnosti použít 32 bit dll. Díky. Jaroslav Hurdes OS Windows 7, x64 Verze javy (32 bit) java version 1.6.0_31 Java(TM) SE Runtime Environment (build 1.6.0_31-b05) Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) spouštění aplikace: java -XX:ThreadStackSize=256 -Xss256k -XX:ReservedCodeCacheSize=64m -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9001 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -server -Xcheck:jni -Xmx1024M -Djava.library.path=..\common\lib\native -jar nitta-lp-rec-srv.jar ./cfg %* -- S pozdravem Roman Dagi Pichlik /* -- :J
Re: java.lang.OutOfMemoryError: unable to create new native thread
To je v pořádku, nepsal jsem, že daná aplikace je jediná na PC, Ve skutečnosti je tam daná aplikace spuštěna několikrát (zpracováni obrazu z více kamer, v tomto konkrétním případě 2x) + databáze + AS JBoss + OS a další programy. Jedna instance problematické aplikace má nastaveno Xmx na 1024m. Jaroslav Hurdes Dne 13.4.2012 11:03, Jiří Zůna napsal(a): Zdravim, Na vasem popisu situace me zaujalo max. 12GB pameti a 33%-ni vuziti (takze +- 4GB obsazene pameti). A ted moje silena domnenka: Java je pouze 32bit proces, tudiz dal nez za 4GB nevidi a pamet pro stack se alokuje mimo heapu (a samozrejme i mimo permgen). Myslim si, ze pro javu se v tech jejich ctyrech gigabajtech uz nenajde misto pro novy stack pro nove vlakno (muze tam byt os, dalsi programy, ...) a tak skonci s OOM, idkyz je vlastne 66% pameti nevyuzite. Jestli to ale skutecne tak muze byt, si nejsem jisty. Hodne zdaru, :J On Thursday, April 12, 2012, Jaroslav Hurdes wrote: Systém má k dispozici 12 GB RAM. Využití paměti je na cca 33% CPU 20% Procesu cca 70, Threadu cca 5000 na cely OS, takže docela v pohodě. Jaroslav Hurdes Dne 12.4.2012 20:59, Peter Hanuliak napsal(a): skusali ste pozriet ako vyzeraju zdroje windows systemu? ako on vyzera s threadmi? pamatou a pod? 2012/4/12 Roman Pichlíkroman.pich...@gmail.com: hmm je uz to opravdu jenom strelba od boku, co zkusit nastavit PermSpace? 2012/4/12 Jaroslav Hurdesj...@ataco.cz: Ne, tato třída nemá s JNI nic společného. Je to jednoduchý server, který na požádání vytvoří thread, obslouží požadavek a ukonči se. Tato třída má na svědomí ten celkový počet spuštěných threadu, které ale žijí jen velmi krátce (klient se zeptá na stav aplikace a po odeslání zprávy je thread ukončen). Jaroslav Hurdes Dne 12.4.2012 20:13, Roman Pichlík napsal(a): Vola se to JNI v ramci CommandClientsManager$Client.start? 2012/4/12 Jaroslav Hurdesj...@ataco.cz: Vláken je spuštěno pouze 26, viz výpis z dokumentace k jconsole Threads Live threads: Current number of live daemon threads plus non-daemon threads Peak: Highest number of live threads since JVM started. Daemon threads: Current number of live daemon threads Total started: Total number of threads started since JVM started (including daemon, non-daemon, and terminated). DLL je volána přes JNI a nemělo by tam vzniknout souběžně více vláken (získávání obrazu z frame grabberu). Jaroslav Hurdes Dne 12.4.2012 19:26, Roman Pichlík napsal(a): To je pocet celkove vytvorenych vlaken po dobu behu, nikoliv zivych, tech je tam relativne malo, 67 pokud dobre pocitam. 2012/4/12 Martin Caslavskymartin-l...@geek.cz: Máte 2.500 vláken a další už nejde vytvořit... První odkaz v Google popisuje tenhle problém: http://stackoverflow.com/questions/763579/how-many-threads-can-a-java-vm-support Martin Caslavsky On 12 April 2012 18:08, Jaroslav Hurdesj...@ataco.czwrote: Zdravím, bojuji s vyjímkou, která nastává v mé aplikaci a nedaří se mi objevit příčinu. Vyjímka je následující: Exception in thread Thread-6 java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:640) at cz.nitta.licenceplate.server.business.communicator.CommandClientsManager$Client.start(CommandClientsManager.java:357) at cz.nitta.licenceplate.server.business.communicator.CommandClientsManager.addClient(CommandClientsManager.java:118) at cz.nitta.licenceplate.server.business.communicator.ClientsGatekeeper.addClient(ClientsGatekeeper.java:196)
Jak na vlákna v J2EE
Chtěl jsem se zeptat na váš názor nebo zkušenost s prací ve vláknech J2EE
aplikací?
Četl jsem doporučení, že by se vlákna neměla v J2EE vytvářet resp., že jsou
doporučené metody jak to bezpečně dělat (pomocí různých implementací timerů
atd.).
Řeším problém, kdy vlákno (request) potřebuje udělat tři dotazy do třech
různých databází a ty sloučit do jednoho výsledku. Je velmi pomalé čekat na
doběh jednotlivých dotazů, které jsou na sobě nezávislé.
Navrhl jsem pro začátek něco takového viz. níže, ale nejsem si jist jestli
tam není nějaká záludnost:
/** definice pracovní třídy pro práci s DB (obsahuje vše potřebné k načtení
dat) */
public class DbWorker implements CallableResult {
...
}
/** voláno z requestu */
ExecutorService executor = Executors.newFixedThreadPool(MAX_THREADS);
ListFutureResult res = new ArrayListFutureInteger();
for (DbTask task : tasks) {
// načtení dat
res.add(executor.submit(new DbWorker(task, ...)));
}
// čekej na dokončení vláken
// Zpracování načtených dat
for (FutureInteger future : res) {
System.out.println(future.get());
}
Petr
Re: Jak na vlákna v J2EE
Ahoj,
dal bych prednost asynchronnim metodam v EJB 3.1.
Z.
--
Zdenek Tronicek
FIT CTU in Prague
Petr Franta napsal(a):
Chtěl jsem se zeptat na váš názor nebo zkušenost s prací ve vláknech J2EE
aplikací?
Četl jsem doporučení, že by se vlákna neměla v J2EE vytvářet resp., že
jsou
doporučené metody jak to bezpečně dělat (pomocí různých implementací
timerů
atd.).
Řeším problém, kdy vlákno (request) potřebuje udělat tři dotazy do třech
různých databází a ty sloučit do jednoho výsledku. Je velmi pomalé čekat
na
doběh jednotlivých dotazů, které jsou na sobě nezávislé.
Navrhl jsem pro začátek něco takového viz. níže, ale nejsem si jist jestli
tam není nějaká záludnost:
/** definice pracovní třídy pro práci s DB (obsahuje vše potřebné k
načtení
dat) */
public class DbWorker implements CallableResult {
...
}
/** voláno z requestu */
ExecutorService executor = Executors.newFixedThreadPool(MAX_THREADS);
ListFutureResult res = new ArrayListFutureInteger();
for (DbTask task : tasks) {
// načtení dat
res.add(executor.submit(new DbWorker(task, ...)));
}
// čekej na dokončení vláken
// Zpracování načtených dat
for (FutureInteger future : res) {
System.out.println(future.get());
}
Petr
Re: Jak na vlákna v J2EE
V J2EE se namísto toho využije aplikační server a pomocí message se pošle
pokyn k vykonání nějaké asynchronní operace.
Podívejte se třeba na
http://www.java2s.com/Code/Java/EJB3/EJBTutorialfromJBossdemoformessagedrivenbean.htm
Protože jste toto asi ještě nepoužil, ještě napovím, že zpráva může být
různých typů včetně java.lang.Object
Jirka Chaloupka
Dne 13. dubna 2012 14:33 Petr Franta petr.fra...@gmail.com napsal(a):
Chtěl jsem se zeptat na váš názor nebo zkušenost s prací ve vláknech J2EE
aplikací?
Četl jsem doporučení, že by se vlákna neměla v J2EE vytvářet resp., že
jsou doporučené metody jak to bezpečně dělat (pomocí různých implementací
timerů atd.).
Řeším problém, kdy vlákno (request) potřebuje udělat tři dotazy do třech
různých databází a ty sloučit do jednoho výsledku. Je velmi pomalé čekat na
doběh jednotlivých dotazů, které jsou na sobě nezávislé.
Navrhl jsem pro začátek něco takového viz. níže, ale nejsem si jist jestli
tam není nějaká záludnost:
/** definice pracovní třídy pro práci s DB (obsahuje vše potřebné k
načtení dat) */
public class DbWorker implements CallableResult {
...
}
/** voláno z requestu */
ExecutorService executor = Executors.newFixedThreadPool(MAX_THREADS);
ListFutureResult res = new ArrayListFutureInteger();
for (DbTask task : tasks) {
// načtení dat
res.add(executor.submit(new DbWorker(task, ...)));
}
// čekej na dokončení vláken
// Zpracování načtených dat
for (FutureInteger future : res) {
System.out.println(future.get());
}
Petr
Re: Jak na vlákna v J2EE
No já myslím, že Petr bude ještě potřebovat nějakou synchronizaci až
se data načtou.
V Tvém případě v JEE prostředí můžeš použít vlákna, protože tvoje
metoda je vlastně synchronní, jen jistá část kódu se kvůli výkonu volá
asynchronně. Akorát v těch vláknech nemůžeš používat JEE věci, jako je
např. přístup k DB. Ale i tak by bylo pravděpodobně lepší použít
některý z navrhovných způsobů.
2012/4/13 Jiří Chaloupka k...@chalu.cz:
V J2EE se namísto toho využije aplikační server a pomocí message se pošle
pokyn k vykonání nějaké asynchronní operace.
Podívejte se třeba na
http://www.java2s.com/Code/Java/EJB3/EJBTutorialfromJBossdemoformessagedrivenbean.htm
Protože jste toto asi ještě nepoužil, ještě napovím, že zpráva může být
různých typů včetně java.lang.Object
Jirka Chaloupka
Dne 13. dubna 2012 14:33 Petr Franta petr.fra...@gmail.com napsal(a):
Chtěl jsem se zeptat na váš názor nebo zkušenost s prací ve vláknech J2EE
aplikací?
Četl jsem doporučení, že by se vlákna neměla v J2EE vytvářet resp., že
jsou doporučené metody jak to bezpečně dělat (pomocí různých implementací
timerů atd.).
Řeším problém, kdy vlákno (request) potřebuje udělat tři dotazy do třech
různých databází a ty sloučit do jednoho výsledku. Je velmi pomalé čekat na
doběh jednotlivých dotazů, které jsou na sobě nezávislé.
Navrhl jsem pro začátek něco takového viz. níže, ale nejsem si jist jestli
tam není nějaká záludnost:
/** definice pracovní třídy pro práci s DB (obsahuje vše potřebné k
načtení dat) */
public class DbWorker implements CallableResult {
...
}
/** voláno z requestu */
ExecutorService executor = Executors.newFixedThreadPool(MAX_THREADS);
ListFutureResult res = new ArrayListFutureInteger();
for (DbTask task : tasks) {
// načtení dat
res.add(executor.submit(new DbWorker(task, ...)));
}
// čekej na dokončení vláken
// Zpracování načtených dat
for (FutureInteger future : res) {
System.out.println(future.get());
}
Petr
--
Ondra Medek
Re: java.lang.OutOfMemoryError: unable to create new native thread
Ahoj, pamet i celkovy pocet vlaken se mi zdaji v poradku. Podival bych se na pocet otevrenych souboru. Nejsou tam nejake pracovni soubory? Z. -- Zdenek Tronicek FIT CTU in Prague Jaroslav Hurdes napsal(a): To je v pořádku, nepsal jsem, že daná aplikace je jediná na PC, Ve skutečnosti je tam daná aplikace spuštěna několikrát (zpracováni obrazu z více kamer, v tomto konkrétním případě 2x) + databáze + AS JBoss + OS a další programy. Jedna instance problematické aplikace má nastaveno Xmx na 1024m. Jaroslav Hurdes Dne 13.4.2012 11:03, Jiří Zůna napsal(a): Zdravim, Na vasem popisu situace me zaujalo max. 12GB pameti a 33%-ni vuziti (takze +- 4GB obsazene pameti). A ted moje silena domnenka: Java je pouze 32bit proces, tudiz dal nez za 4GB nevidi a pamet pro stack se alokuje mimo heapu (a samozrejme i mimo permgen). Myslim si, ze pro javu se v tech jejich ctyrech gigabajtech uz nenajde misto pro novy stack pro nove vlakno (muze tam byt os, dalsi programy, ...) a tak skonci s OOM, idkyz je vlastne 66% pameti nevyuzite. Jestli to ale skutecne tak muze byt, si nejsem jisty. Hodne zdaru, :J On Thursday, April 12, 2012, Jaroslav Hurdes wrote: Systém má k dispozici 12 GB RAM. Využití paměti je na cca 33% CPU 20% Procesu cca 70, Threadu cca 5000 na cely OS, takže docela v pohodě. Jaroslav Hurdes Dne 12.4.2012 20:59, Peter Hanuliak napsal(a): skusali ste pozriet ako vyzeraju zdroje windows systemu? ako on vyzera s threadmi? pamatou a pod? 2012/4/12 Roman Pichlíkroman.pich...@gmail.com: hmm je uz to opravdu jenom strelba od boku, co zkusit nastavit PermSpace? 2012/4/12 Jaroslav Hurdesj...@ataco.cz: Ne, tato třída nemá s JNI nic společného. Je to jednoduchý server, který na požádání vytvoří thread, obslouží požadavek a ukonči se. Tato třída má na svědomí ten celkový počet spuštěných threadu, které ale žijí jen velmi krátce (klient se zeptá na stav aplikace a po odeslání zprávy je thread ukončen). Jaroslav Hurdes Dne 12.4.2012 20:13, Roman Pichlík napsal(a): Vola se to JNI v ramci CommandClientsManager$Client.start? 2012/4/12 Jaroslav Hurdesj...@ataco.cz: Vláken je spuštěno pouze 26, viz výpis z dokumentace k jconsole Threads Live threads: Current number of live daemon threads plus non-daemon threads Peak: Highest number of live threads since JVM started. Daemon threads: Current number of live daemon threads Total started: Total number of threads started since JVM started (including daemon, non-daemon, and terminated). DLL je volána přes JNI a nemělo by tam vzniknout souběžně více vláken (získávání obrazu z frame grabberu). Jaroslav Hurdes Dne 12.4.2012 19:26, Roman Pichlík napsal(a): To je pocet celkove vytvorenych vlaken po dobu behu, nikoliv zivych, tech je tam relativne malo, 67 pokud dobre pocitam. 2012/4/12 Martin Caslavskymartin-l...@geek.cz: Máte 2.500 vláken a další už nejde vytvořit... První odkaz v Google popisuje tenhle problém: http://stackoverflow.com/questions/763579/how-many-threads-can-a-java-vm-support Martin Caslavsky On 12 April 2012 18:08, Jaroslav Hurdesj...@ataco.czwrote: Zdravím, bojuji s vyjímkou, která nastává v mé aplikaci a nedaří se mi objevit příčinu. Vyjímka je následující: Exception in thread Thread-6 java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:640) at cz.nitta.licenceplate.server.business.communicator.CommandClientsManager$Client.start(CommandClientsManager.java:357) at
Re: Jak na vlákna v J2EE
Jo a také použitím vláken ztrácíš trochu kontrolu nad aplikací. V JEE
si typicky nastavíš, že chces třeba max. 100 aktivních bean (100
vláken), ale jakmile si začneš tvořit vlákna sám, tak už žádný limit
udělat nemůžeš. Také proto by se ty vlákna něměly dělat, ale čistě
technicky to samozřejmě lze.
2012/4/13 Ondra Medek xmed...@gmail.com:
No já myslím, že Petr bude ještě potřebovat nějakou synchronizaci až
se data načtou.
V Tvém případě v JEE prostředí můžeš použít vlákna, protože tvoje
metoda je vlastně synchronní, jen jistá část kódu se kvůli výkonu volá
asynchronně. Akorát v těch vláknech nemůžeš používat JEE věci, jako je
např. přístup k DB. Ale i tak by bylo pravděpodobně lepší použít
některý z navrhovných způsobů.
2012/4/13 Jiří Chaloupka k...@chalu.cz:
V J2EE se namísto toho využije aplikační server a pomocí message se pošle
pokyn k vykonání nějaké asynchronní operace.
Podívejte se třeba na
http://www.java2s.com/Code/Java/EJB3/EJBTutorialfromJBossdemoformessagedrivenbean.htm
Protože jste toto asi ještě nepoužil, ještě napovím, že zpráva může být
různých typů včetně java.lang.Object
Jirka Chaloupka
Dne 13. dubna 2012 14:33 Petr Franta petr.fra...@gmail.com napsal(a):
Chtěl jsem se zeptat na váš názor nebo zkušenost s prací ve vláknech J2EE
aplikací?
Četl jsem doporučení, že by se vlákna neměla v J2EE vytvářet resp., že
jsou doporučené metody jak to bezpečně dělat (pomocí různých implementací
timerů atd.).
Řeším problém, kdy vlákno (request) potřebuje udělat tři dotazy do třech
různých databází a ty sloučit do jednoho výsledku. Je velmi pomalé čekat na
doběh jednotlivých dotazů, které jsou na sobě nezávislé.
Navrhl jsem pro začátek něco takového viz. níže, ale nejsem si jist jestli
tam není nějaká záludnost:
/** definice pracovní třídy pro práci s DB (obsahuje vše potřebné k
načtení dat) */
public class DbWorker implements CallableResult {
...
}
/** voláno z requestu */
ExecutorService executor = Executors.newFixedThreadPool(MAX_THREADS);
ListFutureResult res = new ArrayListFutureInteger();
for (DbTask task : tasks) {
// načtení dat
res.add(executor.submit(new DbWorker(task, ...)));
}
// čekej na dokončení vláken
// Zpracování načtených dat
for (FutureInteger future : res) {
System.out.println(future.get());
}
Petr
--
Ondra Medek
--
Ondra Medek
Re: Jak na vlákna v J2EE
Tu synchronizaci tam, kde potřebuji dělám tak, že mám informaci o nějakém
systémovém úkolu, jehož identifikátor posílám v message, a ve chvíli, kdy
se úkol dokončí, tak se k němu zapíše výsledek.
Jirka
2012/4/13 Ondra Medek xmed...@gmail.com
No já myslím, že Petr bude ještě potřebovat nějakou synchronizaci až
se data načtou.
V Tvém případě v JEE prostředí můžeš použít vlákna, protože tvoje
metoda je vlastně synchronní, jen jistá část kódu se kvůli výkonu volá
asynchronně. Akorát v těch vláknech nemůžeš používat JEE věci, jako je
např. přístup k DB. Ale i tak by bylo pravděpodobně lepší použít
některý z navrhovných způsobů.
2012/4/13 Jiří Chaloupka k...@chalu.cz:
V J2EE se namísto toho využije aplikační server a pomocí message se pošle
pokyn k vykonání nějaké asynchronní operace.
Podívejte se třeba na
http://www.java2s.com/Code/Java/EJB3/EJBTutorialfromJBossdemoformessagedrivenbean.htm
Protože jste toto asi ještě nepoužil, ještě napovím, že zpráva může být
různých typů včetně java.lang.Object
Jirka Chaloupka
Dne 13. dubna 2012 14:33 Petr Franta petr.fra...@gmail.com napsal(a):
Chtěl jsem se zeptat na váš názor nebo zkušenost s prací ve vláknech
J2EE
aplikací?
Četl jsem doporučení, že by se vlákna neměla v J2EE vytvářet resp., že
jsou doporučené metody jak to bezpečně dělat (pomocí různých
implementací
timerů atd.).
Řeším problém, kdy vlákno (request) potřebuje udělat tři dotazy do třech
různých databází a ty sloučit do jednoho výsledku. Je velmi pomalé
čekat na
doběh jednotlivých dotazů, které jsou na sobě nezávislé.
Navrhl jsem pro začátek něco takového viz. níže, ale nejsem si jist
jestli
tam není nějaká záludnost:
/** definice pracovní třídy pro práci s DB (obsahuje vše potřebné k
načtení dat) */
public class DbWorker implements CallableResult {
...
}
/** voláno z requestu */
ExecutorService executor = Executors.newFixedThreadPool(MAX_THREADS);
ListFutureResult res = new ArrayListFutureInteger();
for (DbTask task : tasks) {
// načtení dat
res.add(executor.submit(new DbWorker(task, ...)));
}
// čekej na dokončení vláken
// Zpracování načtených dat
for (FutureInteger future : res) {
System.out.println(future.get());
}
Petr
--
Ondra Medek
