[Javalist] play / c3p0pooledconn ...

Hollósi Balázs hollosi.balazs at 1101.hu
2012. Jan. 24., K, 23:47:20 CET


mármár azt hittem hogy meghozza a javulást, vagy negyed órán át élt a
rendszer.. :) de persze csatt ez is.

#  Internal Error (synchronizer.cpp:1954), pid=26905, tid=139912350766848
#  guarantee(mid->header()->is_neutral()) failed: invariant
#
# JRE version: 6.0_20-b20
# Java VM: OpenJDK 64-Bit Server VM (19.0-b09 mixed mode linux-amd64 )
# Derivative: IcedTea6 1.9.10
# Distribution: Ubuntu 10.04.1 LTS, package 6b20-1.9.10-0ubuntu1~10.04.2


viszont ez alapján találtam egy rakás hasonló problémát, openvz
jellegű, adott kernel verzió, stb. még végigolvason a thread-eket, de
úgy néz ki ezt a hosting céggel kell elintézni.. szép kis kör lesz :)

http://forum.proxmox.com/archive/index.php/t-6998.html
http://stackoverflow.com/questions/7722756/java-strange-deadlock

b

2012/1/24 Hollósi Balázs <hollosi.balazs at 1101.hu>:
> kiprobaltam -XX:-UseCompressedOops kapcsoloval, remote debug, szepen
> hasal igy is
>
> Internal Error (synchronizer.cpp:1401), pid=23812, tid=139974289278720
> #  guarantee(mid->header()->is_neutral()) failed: invariant
> #
> # JRE version: 6.0_30-b12
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.5-b03 mixed mode linux-amd64 )
>
> ez most sun jdk, de probaltam jrockit-el is, openjdk meg nem volt..
> eddig csak a bajom volt vele, de egy probat meger..
>
>
> 2012/1/24 Gábor Garami <gabor.garami at hron.me>:
>> Akartam is kerdezni, hogy ez amugy milyen jdk? Mert minden sunos jdk-val
>> tamogatott csak.
>>
>> Ezt a levelet telefonról adták fel ezért esetenként ékezethibákat
>> tartalmazhat.
>>
>> Garami Gábor
>> E-mail: gabor.garami at hron.me
>> Web: http://hron.me
>> Skype: hron84
>> MSN: hrgy at vipmail.hu
>>
>> 2012.01.24. 22:35, "Zsombor" <gzsombor at gmail.com> ezt írta:
>>
>>> Én a vm-et cserélném le (openjdk/icedtea/stb), miután végig kerestem, hogy
>>> ilyen gyanús libjvm-ből származó sigsegv-eket látott e bárki is.
>>> Ezenkivül a compressed oops-ot is ki lehetne kapcsolni, úgy rémlik, hogy
>>> az valami új kisérletibb ficsör.
>>>
>>>
>>> On Tue, Jan 24, 2012 at 22:23, Hollósi Balázs <hollosi.balazs at 1101.hu>
>>> wrote:
>>>>
>>>> újabb próba, db -t kizárom, semmi pg speci nincs még, átállítottam
>>>> mysql-re, had szóljon. így meg sorra jönnek a vm crash-ek.. persze
>>>> mindig más, egzotikus..
>>>>
>>>> ----
>>>> #  SIGSEGV (0xb) at pc=0x00007f3ff1cea1ae, pid=10726, tid=139912539502336
>>>> #
>>>> # JRE version: 6.0_30-b12
>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.5-b03 mixed mode
>>>> linux-amd64 compressed oops)
>>>> # Problematic frame:
>>>> # V  [libjvm.so+0x3e91ae]
>>>> DefNewGeneration::copy_to_survivor_space(oopDesc*)+0x3e
>>>> ----
>>>> #  Internal Error (synchronizer.cpp:1399), pid=12266, tid=140560676685568
>>>> #  guarantee(obj->mark() == markOopDesc::encode(mid)) failed: invariant
>>>> ----
>>>> az utóbbinál szimplán megállt 324 request után a loadui kiszolgálása.
>>>> kezd az agyamra menni..
>>>>
>>>> viszont c3p0 kihagyása ha jól láttam csak úgy lehetséges ha j2ee
>>>> konténerben futtatom, és jndi-n keresztül kapja a kapcsolatot.. jöjjön
>>>> hát a glassfish.. grr..
>>>>
>>>> b
>>>>
>>>> 2012/1/24 Gábor Garami <gabor.garami at hron.me>:
>>>> > En se gondolom, h az oom-killer dolgozna, az levagna a komplett
>>>> > appszervert.
>>>> > Inkabb vmi jdbc nyug lehet ez, v. tenyleg a c3p0 problemaja. Esetleg db
>>>> > szerver gond... :-)
>>>> >
>>>> > Ezt a levelet telefonról adták fel ezért esetenként ékezethibákat
>>>> > tartalmazhat.
>>>> >
>>>> > Garami Gábor
>>>> > E-mail: gabor.garami at hron.me
>>>> > Web: http://hron.me
>>>> > Skype: hron84
>>>> > MSN: hrgy at vipmail.hu
>>>> >
>>>> > 2012.01.24. 16:24, "Laszlo Hornyak" <laszlo.hornyak at gmail.com> ezt
>>>> > írta:
>>>> >
>>>> >> Hali!
>>>> >>
>>>> >> Ha a kernel OOM killerre gondolsz, az az egesz processzedet csapja le
>>>> >> szerintem, azaz a JVM-et. Threadeket talan nem lenne ertelme, a
>>>> >> szalaknak nincs sajat memoria szegmensuk.
>>>> >>
>>>> >> 2012/1/24 András Csányi <sayusi.ando at gmail.com>:
>>>> >> > 2012/1/24 Balázs Hollósi <hollosibalazs at gmail.com>:
>>>> >> >> sziasztok
>>>> >> >>
>>>> >> >> igazából olyan vizeken evezek, ahol nem sok helyismeretem van,
>>>> >> >> ezért
>>>> >> >> bármi nemű segítséget köszönök.
>>>> >> >>
>>>> >> >> tehát. van egy play framework webes alkalmazásom, postgres
>>>> >> >> adatbázissal. eddig tök jól ment minden, viszont a hosting cég ahol
>>>> >> >> van (vps) konfigolt egyet, és most érdekességek történnek. a cég
>>>> >> >> alapvetően konstruktív, már átraktak egy másik node-ra, ahol a
>>>> >> >> config
>>>> >> >> ua, de a vas más, ergo a memória hibát meg a többi hw parát úgy
>>>> >> >> gondolom kizárhatom. eddig a vps 4 cpu-t látott (/proc/cpuinfo)
>>>> >> >> most
>>>> >> >> egy magot, amelyik azt mondja magáról hogy 4 magos, gondolom a
>>>> >> >> virtualizáción állítottak, azért lett más, lényegében a sebesség
>>>> >> >> maradt, ezzel sincs gondom.
>>>> >> >>
>>>> >> >> a jelenség hogy egyszercsak felugrik a java process load-ja
>>>> >> >> 100%-ra,
>>>> >> >> még egy darabig működik az alkalmazás, de rosszabb esetben
>>>> >> >> segfault-ol
>>>> >> >> a vm, jobbik esetben izzasztja a vasat, és 4-5ös load mellett azért
>>>> >> >> néha kiszolgál egy-egy requestet. ja igen, demo alkalmazás,
>>>> >> >> bármilyen
>>>> >> >> "eszköz" engedélyezett :)
>>>> >> >>
>>>> >> >> debug módban elindítottam a vm-et, és remote rácsatlakoztam.
>>>> >> >> eclipse
>>>> >> >> alatt szép sorban suspend a szálakra, így meglett a bőnös
>>>> >> >> (legnagyobb
>>>> >> >> meglepetésre nem a play szál).
>>>> >> >>
>>>> >> >> a bűnös thread stack:
>>>> >> >>
>>>> >> >>
>>>> >> >> Daemon Thread
>>>> >> >> [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0]
>>>> >> >> (Suspended)
>>>> >> >>        Finalizer.add() line: 42
>>>> >> >>        Finalizer.<init>(Object) line: 67
>>>> >> >>        Finalizer.register(Object) line: 72
>>>> >> >>        Jdbc4Statement(Object).<init>() line: 20
>>>> >> >>
>>>> >> >>
>>>> >> >>  Jdbc4Statement(AbstractJdbc2Statement).<init>(AbstractJdbc2Connection,
>>>> >> >> int, int) line: 135
>>>> >> >>
>>>> >> >>
>>>> >> >>  Jdbc4Statement(AbstractJdbc3Statement).<init>(AbstractJdbc3Connection,
>>>> >> >> int, int, int) line: 36
>>>> >> >>
>>>> >> >>
>>>> >> >>  Jdbc4Statement(AbstractJdbc3gStatement).<init>(AbstractJdbc3Connection,
>>>> >> >> int, int, int) line: 23
>>>> >> >>
>>>> >> >>  Jdbc4Statement(AbstractJdbc4Statement).<init>(Jdbc4Connection,
>>>> >> >> int,
>>>> >> >> int, int) line: 26
>>>> >> >>        Jdbc4Statement.<init>(Jdbc4Connection, int, int, int) line:
>>>> >> >> 25
>>>> >> >>        Jdbc4Connection.createStatement(int, int, int) line: 30
>>>> >> >>
>>>> >> >>  Jdbc4Connection(AbstractJdbc3Connection).createStatement(int,
>>>> >> >> int) line: 231
>>>> >> >>
>>>> >> >>
>>>> >> >>  Jdbc4DatabaseMetaData(AbstractJdbc2DatabaseMetaData).createMetaDataStatement()
>>>> >> >> line: 4266
>>>> >> >>
>>>> >> >>
>>>> >> >>  Jdbc4DatabaseMetaData(AbstractJdbc2DatabaseMetaData).getTables(String,
>>>> >> >> String, String, String[]) line: 2069
>>>> >> >>
>>>> >> >>  DefaultConnectionTester.activeCheckConnectionNoQuery(Connection,
>>>> >> >> Throwable[]) line: 185
>>>> >> >>        DefaultConnectionTester.activeCheckConnection(Connection,
>>>> >> >> String,
>>>> >> >> Throwable[]) line: 62
>>>> >> >>
>>>> >> >>
>>>> >> >>  DefaultConnectionTester(AbstractConnectionTester).activeCheckConnection(Connection)
>>>> >> >> line: 67
>>>> >> >>
>>>> >> >>
>>>> >> >>  C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.testPooledConnection(Object)
>>>> >> >> line: 368
>>>> >> >>
>>>> >> >>
>>>> >> >>  C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.refurbishIdleResource(Object)
>>>> >> >> line: 310
>>>> >> >>        BasicResourcePool$AsyncTestIdleResourceTask.run() line: 1999
>>>> >> >>        ThreadPoolAsynchronousRunner$PoolThread.run() line: 547
>>>> >> >>
>>>> >> >> ez ha jól tudom db pool cucc. viszont otthon, meg eddig kint is ua
>>>> >> >> verzió (play embeddelt) fut, otthon még most is, kint eddig stabil
>>>> >> >> volt.
>>>> >> >> első körben a kérdésem, találkozott-e már valaki hasonló parával.
>>>> >> >> ismert-e hogy 1 (virtuális) magos környezetben gondok lennének
>>>> >> >> vele? egyéb javaslat?
>>>> >> >>
>>>> >> >> ezer köszi előre is,
>>>> >> >> B
>>>> >> >
>>>> >> > Mindig ez a hiba? Ezt azért kérdezem, mert ha ez a virtualizált
>>>> >> > környezet linux, akkor az is lehet, hogy az a terheltség, amit kap
>>>> >> > elviszi oda az oprendszert, hogy magától elkezdi kinyírni a szálakat
>>>> >> > (nem jut most eszembe, hogy mi a neve ennek a jószágnak a
>>>> >> > kernelben).
>>>> >> >
>>>> >> > --
>>>> >> > - -
>>>> >> > --  Csanyi Andras (Sayusi Ando)  -- http://sayusi.hu --
>>>> >> > http://facebook.com/andras.csanyi
>>>> >> > --  ""Trust in God and keep your gunpowder dry!" - Cromwell
>>>> >> > _______________________________________________
>>>> >> > Javalist mailing list
>>>> >> > Javalist at lists.javaforum.hu
>>>> >> > http://lists.javaforum.hu/mailman/listinfo/javalist
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >>
>>>> >> EOF
>>>> >> _______________________________________________
>>>> >> Javalist mailing list
>>>> >> Javalist at lists.javaforum.hu
>>>> >> http://lists.javaforum.hu/mailman/listinfo/javalist
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Javalist mailing list
>>>> > Javalist at lists.javaforum.hu
>>>> > http://lists.javaforum.hu/mailman/listinfo/javalist
>>>> >
>>>> _______________________________________________
>>>> Javalist mailing list
>>>> Javalist at lists.javaforum.hu
>>>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>>
>>>
>>>
>>> _______________________________________________
>>> Javalist mailing list
>>> Javalist at lists.javaforum.hu
>>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>>
>>
>> _______________________________________________
>> Javalist mailing list
>> Javalist at lists.javaforum.hu
>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>


További információk a(z) Javalist levelezőlistáról