Re: [Resin-interest] Out of PermGen space
On 4/24/2012 5:13 PM, Bill Au wrote: Wow, something I'm actually qualified to talk about on this list! :) > Out of PermGen space is almost always caused by a classloader leak which > occurs when a webapp is reloaded. It could be caused by either your own > code, third-party code, or in some case Java core classes. I debug PermGen errors quite a bit. Some of our apps have a cache of dynamically generated classes (Drools does this) that, if held onto long enough, will make the the JVM run out of PermGen. This isn't really a mistake, it's just how it works, sadly. > You need to take heap dumps before and after webapp reload and use a > heap analyzer to see what is holding onto the leaked classloader(s). That's how I debug them. Take a series of heap dumps and start comparing the differences between them -- YourKit even makes this easy for you with a tool that diffs heap dumps. - Matt ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Out of PermGen space
Thanks, Mattias, that's cool! -- Rick On Apr 24, 2012, at 22:17 , Mattias Jiderhamn wrote: > Hi Rick. > > After having had these issues for years, I started blogging about it and how > to find classloader leaks [1]. I also compiled a list of API calls and third > party libraries known to trigger these leaks [2], and as you can see, it is > quite common both to cause these problems yourself and to have them caused by > some dependency. > > Having done the research, I ended up creating a small library that you can > add to you web application, that will clean up strong references keeping > your classloader from being garbage collected [3]. Somewhat like Tomcat has > built in, but taking care of more of the known problems. I suggest you add > this library to you app and watch the logs (feel free to report your > findings). > > Having said that, I should admit that I'm still seeing PermGen crashes > running under Resin, even when there are no visible strong references to > my classloader. I have not had time to investigate whether this is caused by > Resin (such as the HotSwap capability), or if it is some JVM bug (and > possibly something with IntelliJ, as the problem increases using the IntelliJ > Resin plugin). I should probably try turning HotSwap off, or try another > application server - or another JVM. Someday... > > Good luck! > > > > 1: > http://java.jiderhamn.se/2011/12/11/classloader-leaks-i-how-to-find-classloader-leaks-with-eclipse-memory-analyser-mat/ > 2: > http://java.jiderhamn.se/2012/02/26/classloader-leaks-v-common-mistakes-and-known-offenders/ > 3: > http://java.jiderhamn.se/2012/03/04/classloader-leaks-vi-this-means-war-leak-prevention-library/ > > > - Original Message - > Subject: [Resin-interest] Out of PermGen space > Date: Tue, 24 Apr 2012 13:54:40 -0700 > From: Rick Mann > > When I'm making changes to the code of a webapp, Resin kindly reloads it for > me. I can usually get a handful of reloads in before Resin complains > about being out of PermGen space. > > Is there something I'm doing wrong in my app that it leaks like this? > > -- > Rick > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest > > > -- > > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Fwd: Resin pro 3.1.9 crash JVM on readNative memcpy
Hi, we've been running resin pro 3.1.9 for over a year, just recently, we start to experience regular JVM crashes inside resin native code, Is this a known issue with resin? Thanks, Rock --- T H R E A D --- Current thread (0x2aaed023c000): JavaThread "empty" daemon [_thread_in_native, id=22934, stack(0x4323d000,0x4333e000)] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x003604151000 Registers: RAX=0x, RBX=0xffe6, RCX=0x069c, RDX=0xffdf RSP=0x43338418, RBP=0x2aaecc080da0, RSI=0x003604151000, RDI=0x2aaecc081915 R8 =0x6f45, R9 =0x0101010101010101, R10=0x, R11=0x4000 R12=0xffe6, R13=0x0036041504d9, R14=0x2aaecc080dbc, R15=0x433384d0 RIP=0x00360027c39b, EFL=0x00010206, CSGSFS=0x0033, ERR=0x0004 TRAPNO=0x000e Top of Stack: (sp=0x43338418) 0x43338418: 003603ede7ee 0419 0x43338428: 0419 0024 0x43338438: 000a 0036041500c0 0x43338448: 003603edb99f 0018 0x43338458: 43338490 0012 0x43338468: 2aaef01c8220 433384cc 0x43338478: 000103ff 433384b0 0x43338488: fc0b481ee050 0036041305c0 0x43338498: 0x433384a8: 2aaecc080da0 4d8e 0x433384b8: 6f45 2aaef01c821c 0x433384c8: 03eca32c d69070808e91a963 0x433384d8: 0eb029281f7ba2a8 00368aa63a9c 0x433384e8: 2a8be01c0c00 0036041504f8 0x433384f8: 2aaef01c821c 4acaa0a0 0x43338508: 2aaecd68df30 0x43338518: 000b 433386e0 0x43338528: 003603edb236 2aaef01c821c 0x43338538: 003608a1a16d 2130 0x43338548: 4acaa0a0 0x43338558: 2130 000b 0x43338568: 003608a1a8f1 0001 0x43338578: 003603e7631a 4f8f701b 0x43338588: 4acaa0a0 0003 0x43338598: 0003 2210 0x433385a8: 003608a22de2 433386e0 0x433385b8: 003600274e2e 0068 0x433385c8: 012e 019100010316 0x433385d8: 00360301038d 2aaef01c8350 0x433385e8: 2a8be01c0c00 0x433385f8: 4acaa0a0 2aaef0cbe340 0x43338608: 2210 Instructions: (pc=0x00360027c39b) 0x00360027c38b: 0f 47 da 4c 89 d9 49 83 e3 f8 48 c1 e9 03 74 05 0x00360027c39b: f3 48 a5 66 90 4c 29 da 48 f7 c2 f8 ff ff ff 75 Stack: [0x4323d000,0x4333e000], sp=0x43338418, free space=1005k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libc.so.6+0x7c39b] memcpy+0x15b Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j com.caucho.vfs.JniSocketImpl.readNative(J[BIIJ)I+0 j com.caucho.vfs.JniSocketImpl.read([BIIJ)I+10 j com.caucho.vfs.JniStream.read([BII)I+42 J com.caucho.vfs.ReadStream.readBuffer()Z J com.caucho.server.port.TcpConnection.run()V J com.caucho.util.ThreadPool$Item.runTasks()V j com.caucho.util.ThreadPool$Item.run()V+106 j java.lang.Thread.run()V+11 v ~StubRoutines::call_stub VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap PSYoungGen total 1155712K, used 13482K [0x2aad68cb, 0x2aaddbc9, 0x2aaebe20) eden space 1130496K, 1% used [0x2aad68cb,0x2aad699da970,0x2aadadcb) from space 25216K, 0% used [0x2aadda3f,0x2aadda3f,0x2aaddbc9) to space 48704K, 0% used [0x2aadd5d7,0x2aadd5d7,0x2aadd8d0) PSOldGentotal 2271552K, used 1520627K [0x2aaabe20, 0x2aab48c5, 0x2aad68cb) object space 2271552K, 66% used [0x2aaabe20,0x2aab1aefcd68,0x2aab48c5) PSPermGen total 118592K, used 83492K [0x2e20, 0x2aaab55d, 0x2aaabe20) object space 118592K, 70% used [0x2e20,0x2aaab3389070,0x2aaab55d) Dynamic libraries: VM Arguments: jvm_args: -Djava.util.logging.manager=com.caucho.log.LogManagerImpl -Djava.system.class.loader=com.caucho.loader.SystemClassLoader -Djavax.management.builder.initial=com.caucho.jmx.MBeanServerBuilderImpl -Djava.awt.headless=true -Dresin.home=/usr/local/resin/resin-pro-3.1.9/ -Xms2560m -Xmx16384m -Xss1m -XX:MaxPermSize=256m -verbose:gc -Dcom.sun.management.jmxremote -Dxr.util-logging.loggingEnabled=false -Dcom.sun.management.snmp.port
Re: [Resin-interest] Resin Pro 4.0.24 w/Quercus trying to get MediaWiki 1.18.2 to work..
On Apr 23, 2012, at 7:27 PM, Howard Leadmon wrote: > I really thought since Caucho seems to be using mediawiki, that it would > be a piece of cake to get it working under resin. That said, I have taken > and downloaded the current mediawiki, and went about configuring it up as a > virtual host on my Resin PRO server, got the directories made, archived > expanded out, and even went to the caucho wiki and grabbed the template they > provide to configure. > > All went well, I went to the page, and up came the opening page just fine, > but of course as it was new it asked me to click to configure which I did. > It asked me for my language, which defaulted to English which was fine, and > then I clicked Continue. At that point it put up a nice red stop symbol, > and gave the following error: > > Your session data was lost! Check your php.ini and make sure > session.save_path is set to an appropriate directory. > > Is there any solution to this, and if so my google fu is failing me today, > as I can't seem to find it. If anyone has any hints or suggestions on how to > fix this, I would most appreciate it.. Hi Howard, I believe Mediawiki works on Resin 4.0.27. Some Quercus fixed were made to get our wiki up to version 1.18.2, and these have been included in the latest Resin release. Thanks, Paul > > > --- > Howard Leadmon - how...@leadmon.net > > > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest === Paul Cowan, Software Engineer Caucho Technology co...@caucho.com http://blog.caucho.com http://twitter.com/cauchoresin ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
