[ bjevta @ 05.06.2012. 09:05 ] @
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
...
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
...
java.net.NoRouteToHostException: Cannot assign requested address
-------------
Platforma: Ubuntu Linux+MySQL 5.5

prilikom load test kolega je dobio exception(s). E, sad, posto je vezan za bazu , o'ma' prst uperen u MySQL. ja nesto sumnjam da je to bas do baze, pa sam malo progugulao i nasao jedan od linkova http://blog.griddynamics.com/2...-hessian-methods-leads-to.html koji upucuje na TCP/IP, socket-e i SO_REUSEADDR.

trenutno nemam blage veze gde da trazim resenje pa, ako je neko vec imao slican problem, moze tip?
[ Miroslav Strugarevic @ 05.06.2012. 10:15 ] @
Tip: ulimit -n
[ bogdan.kecman @ 05.06.2012. 10:57 ] @
ta greska znaci da konektor ne moze da se okaci na mysql

- max connections na mysql-u je dostignut (i mysql vise ne prima konekcije)
- max open files na mysql-u je dostignut
- max broj tredova/konekcija na serveru gde je java je dostignut

verovatno ne koristite connection pool nego otvarate direkt konekcije ka mysql-u a ne zatvarate ih nego cekate da same umru - pa vam je to potpuno normalno ponasanje. Napravite connection pool ka mysql-u i koristite ga, tako mozete da kontrolisete koliko max konekcija imate ka bazi.

za max connections - povecajte max connections na mysql-u
za open files - povecajte max open files za mysql (/etc/security/limit.conf + my.cnf)
za broj tredova/konekcija na serveru gde je java isto mora /etc/security/limit.conf da se sredi

[ bjevta @ 05.06.2012. 11:32 ] @
koristimo Tomcat connection pool
ulimits je ok
[ bogdan.kecman @ 05.06.2012. 13:24 ] @
uh, na zalost tomcat je poznat po tome sto mu taj pool ne valja ni za ... :( zato sam ja presao na glassfish

elem, pogledaj na mysql-u koliko imas konekcija kreiranih u trenutku kada dobijes tu gresku
[ bjevta @ 05.06.2012. 15:07 ] @
show processlist pokazuje da baza ne radi skoro nista - nekoliko thread-ova i to je sve.

medjutim, "netstat -a" pokazuje gomilu zauzetih socket-a u statusu TIME_WAIT i skoro svi gadjaju bazu (MySQL port)

connection pool je ovaj novi, iz Tomcat-a 7: http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html je l' za taj kazes da ne valja ili si mislio na onaj stari, DBCP?
[ bogdan.kecman @ 05.06.2012. 21:29 ] @
ne koristim ja tomcat godinama, kao sto rekoh, presao na GF, tomcat se pokazao previse nestabilan.

ako vidis gomilu tih konekcija a mysql kulira, to znaci da TC ne ume da koristi pool kako treba ili da ti ne koristis pool kako treba, kako god okrenes, nesto je do TC-a i do tvoje aplikacije.
[ tarla @ 05.06.2012. 21:48 ] @
Možeš li se sa mašine na kojoj se vrti aplikacija okačiti na MySQL (mysql -h HOST -u USER -p ) ?

NoRouteToHost mi nekako miriše da ga na momente ne vidi... Ili neki firewall blokira port...
[ bantu @ 05.06.2012. 21:55 ] @
Baci parče koda gdje radiš sa bazom pa možda je tu problem. Mada ćeš za to bolju podršku dobiti na Java podforumu.
[ bogdan.kecman @ 05.06.2012. 22:14 ] @
ako ima na serveru brdo konekcija u time wait znaci da mu je pool pobrljaveo

TIME_WAIT konekcija je u ACTIVE CLOSE stanju. Odatle konekcija moze da ide samo u CLOSE

negde pravi problem
- ili otvara i zatvara konekcije bez razloga
- ili ne moze da uspostavi konekciju kako treba

u cemu je fora, ako se dobro secam to go*no od pool-a na tom pos*anom app serveru (ozbiljno razmisli da predjes na gf3 ili na ibm ili na nesto trece TC je fuj) po defaultu ima foru da na "svaku gresku" radi rekonekciju svih konekcija. Sta se onda desi, ti imas 1 konekciju koja radi i pool napravi jos 100 konekcija npr koje cekaju i vrte se u prazno posto tvoj app idluje. Onda prodje timeout i mysql otkaci svih tih 100 konekcija, onda tebi zatreba jos konekcija posto si dobio usera koji zahteva novu konekciju, glupavi pool ti da neispravnu konekciju (timeoutovala je ali pool to ne zna), ti uzmes tu konekciju i ona "ne radi", ti onda u aplikaciji treba da kazes pool-u da mu ta konekcija ne radi i on treba da je ubije i da tebi da drugu. Ako ti ne vratis pool-u pravilno tu konekciju nego samo puknes exception pool skonta da ima gresku i zatvori SVE konekcije i otvori ih opet (ubijajuci i sve aktivne i sve neaktivne u tom trenutku) .... onda ti dobijes neku konekciju opet brdo njih timeoutuje i opet sve ispocetka .. e sad posto njemu ono zatvaranje ne radi bas kako treba ostane mu milion konekcija da "visi" jer ceka da ih zatvori garbage kolektor, a u destruktoru mysql konektora se ne zatvara konekcija pa ista ostane da visi dok je operativni sistem ne ubije... tako neke nebuloze .. tako da se toga nakupi i ti onda vise u jednom trenutku iz tog procesa ne mozes da otvoris novu konekciju i dobijas tako glupave poruke (tipa no route). Druga varijanta je da on ne zatvara sve konekcije nego samo tu koju mu ti vratis da ne valja, opet je slicna prica, da li mu ti pravilno kazes da je konekcija umrla ili on treba to da pretpostavi .. i tu sad ima milion idiotluka TC-a koje treba izbeci ..

Sve u svemu, kombinacija je
- pravilnog konfigurisanja TC jdbc pool-a
- pravilnog uzimanja i vracanja konekcija
- pravilnog obavestavanja TC-a u slucaju da konekcija ne valja

ako bilo sta od toga uradis lose - imaces probleme. Kako da sve tri stvari odradis da valja - uvatis neki java/tc forum pa se nadas da ce neko iskusan da se javi, ja sam probo vise puta i na kraju od*ebo to go*no i instalirao GF (prvo 2, sada 3) i mene glava vise ne boli :)

Naravno uvek postoji mogucnost da
- mysql server to otkacinje zato sto je tamo neki "protection" servis tipa selinux, fail2ban i slicno zakljucio da pravis mnogo konekcija pa te dodao na neki black list
- pogresno si upisao port ili ip ili tako nesto od mysql-a pa stvarno ne moze da se konektuje (jdbc nije bas nesto preterano inteligentan, ko ga osmisli..)
...

[ bjevta @ 06.06.2012. 12:32 ] @
definitivno Tomcat connection pool. Probali sa c3p0 i stanje socket-a je sasvim ocekivano, nekoliko ESTABLISHED i to je sve.

revertovali smo na c3p0 za sad.
[ bogdan.kecman @ 06.06.2012. 12:55 ] @
ja nisam sed covek, ali mislim da su svi ovi sedi pramenovi sto imam u bradi i brkovima posedeli za tih 6-7 meseci maltretiranja sa tim g*vnom od tomcat-a. GlassFish je taaaaaaaaako lep za rad u poredjenju, moja iskrena preporuka, isto je open source, free ovo ono.. :). Cuo sam i za onaj IBM-ov da je isto pesma .. nisam probao ..
[ bjevta @ 06.06.2012. 13:01 ] @
bogi, 'aj' ako te ne mrzi, napisi bar neki konkretan razlog zasto je staklena ribica bolja od macka toma.
[ bogdan.kecman @ 06.06.2012. 13:24 ] @
nit je ovo odgovarajuci forum, nit sam ja odgovarajuca osoba za to poredjenje. TC default jdbc connection pool ne radi kako treba, osim ako ne koristis neke magije da izbegnes sve njegove zamke. Ja nisam uspeo da ga nateram da radi kako treba a imao sam pomoc vajnih "experata" za doticni (cak i ljude iz tima koji ga prave). Resih da probam GF i tamo sve proradilo iz odma. Porasla mi pocupana kosa a aplikacija poletela...

e sad, kao sto rekoh, trose ljudi TC sto znaci ima magija kojom to moze da se natera da radi, verovatno ako ispostujes tajnu proceduru da se drzis za levo uvo i ceses desni guz dok kreiras konekciju onda to radi, otkud znam, ko sto rekoh, nisam expert za TC ali eto - pogledaj kakve ti probleme imas .. sto je najbolje, verovatno je ta procedura negde dokumentovana i na "pravom forumu" ce ti neko reci "e jesi noob, pa samo treba da zabodes iglu ovde, iscedis ono tamo, gurnes prst u ovu rupu i vidi, sad sve radi" .. ja kada sam imao problem izgubio sam nedelju dana na googletu, duplo duze po raznim forumima i na par mesta su mi za resenje rekli "glassfish", i ja reko aj da probam i to cudo, sve proradilo posle 10min, ja od tada ne trosim nista drugo :D