-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Utkarsh,
On 3/30/17 3:34 PM, Utkarsh Dave wrote: > What makes you say that? What makes me say what? > Past cases, I saw where implementation or not using the JSESSION > was making the connection over and over again for multiple > transactions Of course. HTTP is a connectionless protocol, so making many connections with a single session is appropriate. But you are saying that your clients are not re-using sessions and so you want some suggestions. > What JVM are you using? We using Orcale JDK 1.7.0.131 Okay, that's reasonably recent, though still unsupported. I'd move up to Java 8 if possible. > Yes, 58 applications. Okay, then the presence of 58 WebappClassLoader objects in memory is not concerning. I don't see any indications of any problems with "poor socket implementations". If you have 58 applications deployed and you are only using 787MiB of heap, that seems fairly good to me. It's not really clear what you're asking for, here. Can you expand a little bit on what you hope to accomplish? - -chris > On Thu, Mar 30, 2017 at 12:01 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Utkarsh, > > On 3/29/17 7:33 PM, Utkarsh Dave wrote: >>>> Hello all, >>>> >>>> My tomcat (7.0.72) hosts several web aplications in the >>>> server (based in linux 6.8). There are many clients or 3rd >>>> party applications working as client to my server (having >>>> tomcat and web applications). There are instances when poorly >>>> designed client application can affect severly to Tomcat. >>>> Connections/sessions not being reused or closed is one of >>>> them. > > If you have too many sessions, you have two options: > > 1. Lower the session-timeout (default: 30min) 2. Identify places in > the code where sessions are being created but do not need to be > created > >>>> My question is the way to prove/identify such symptoms of the >>>> 3rd party applications. >>>> >>>> I have a situation where all the applications and web/GUI >>>> access slows down and tomcat shows as consuming 100% cpu >>>> (even though overall CPU is less) My diagnosis shows memory >>>> tests for tomcat failing (less than 100KB of free heap left), >>>> And so i generated memory heap dump and thread dumps. Below >>>> are the results. Based on below, does this qualify for a >>>> poorly socket implemetation ? Any thoughts will be helpful. > > What makes you say that? > >>>> Memory heap dump generated is of Size: 787.3 MB Classes: >>>> 139k Objects: 19.3m Class Loader: 1.6k >>>> >>>> Overview shows 580.9 MB occupied by remainder's. >>>> >>>> Problem suspect:- 465 MB occupied by remainder >>>> >>>> 152.2 MB- leak suspect 1 6 instances of >>>> "com.sun.xml.bind.v2.runtime.JAXBContextImpl", loaded by >>>> "org.apache.catalina.loader.WebappClassLoader @ 0xacc38e98" >>>> occupy 159,582,744 (19.33%) bytes. > > It's certainly possible that JAXB and/or your XML-pasring library > could be leaking memory. Older XML parsers would keep the whole > XML document text pinned in memory if some other part of the code > grabbed a single XML attribute and hung-onto the reference. This > was actually fixed in the implementation of String.substring, I > believe. > > What JVM are you using? > >>>> 91 MB- leak suspect 2 58 instances of >>>> "org.apache.catalina.loader.WebappClassLoader", loaded by >>>> "java.net.URLClassLoader @ 0xa6b8e038" occupy 95,396,344 >>>> (11.56%) bytes > > How many applications do you have loaded in the same JVM? If you > have 58, then that's how many WebappClassLoader objects we'd expect > to be present. If you have less than that, you probably have > applications that are not undeploying or reloading cleanly. > >>>> 79.1 MB - leak suspect 3 4 instances of "com.rsa.sslj.x.aO", >>>> loaded by "sun.misc.Launcher$ExtClassLoader @ 0xa6b763b0" >>>> occupy 82,968,424 (10.05%) bytes. > > Is that a 3rd-party JSSE library? > >>>> In the thread dumps I see these threads repeatedly. I wonder >>>> these pointing to com.rsa.sslj.x. >>>> >>>> "http-bio-8443-exec-230" daemon prio=10 tid=0x1130a400 >>>> nid=0x411b runnable [0x01be1000] java.lang.Thread.State: >>>> RUNNABLE at java.net.SocketInputStream.socketRead0(Native >>>> Method) at >>>> java.net.SocketInputStream.read(SocketInputStream.java:153) >>>> at >>>> java.net.SocketInputStream.read(SocketInputStream.java:122) >>>> at com.rsa.sslj.x.ap.c(Unknown Source) at >>>> com.rsa.sslj.x.ap.a(Unknown Source) at >>>> com.rsa.sslj.x.ap.b(Unknown Source) at >>>> com.rsa.sslj.x.ap.b(Unknown Source) at >>>> com.rsa.sslj.x.al.read(Unknown Source) at >>>> org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuff er. > >>>> java:519) >>>> >>>> > at >>>> org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuff er. > >>>> java:504) >>>> >>>> > at >>>> org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout( Htt > >>>> p11Processor.java:168) >>>> >>>> > at >>>> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHt tp1 > >>>> 1Processor.java:998) >>>> >>>> > at >>>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.proces s(A > >>>> bstractProtocol.java:637) >>>> >>>> > at >>>> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpo int > >>>> .java:318) >>>> >>>> > - locked <0x8f1f68d8> (a org.apache.tomcat.util.net.SocketWrapper) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecuto r.j > >>>> ava:1145) >>>> >>>> > at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecut or. > >>>> java:615) >>>> >>>> > at >>>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(Task Thr > >>>> ead.java:61) >>>> >>>> > at java.lang.Thread.run(Thread.java:745) > > That looks like a 3rd-party JSSE library. What do you need that > for? > > -chris >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJY3o7rAAoJEBzwKT+lPKRYUC4P/jPNvkWfDwrSNwKXEu40lRF4 GxeQZeaNYmAFePb7YFNL/BWXvd4/ZznnSpJNKwdgxftfk2uzQfVbNVWXuveZe8x/ 2TpODFXu2PW6X6/SMvtzkojvLeRZwMrG26QQkEC1QtzNIxIX8U/SZzeoBhT64d8i sMmjcKbcNgQkuKa1aF73rz398tG4Nq7O1uxYzSVRYU1enQGo2Xcso0Lw8/zXNvCw JSkdZ/XsmUGjFWR9f0kRBiAT4MkDZlP+JviqZpQoodrnxJYi0erV670Ke5+YC4xp yoMibZZzA6WR0Y0OkqoSVw84+7MRyDfEJ0GlZe3qsyRrgGp8IU9CMX2xmZXy/QI+ ObsSmtgWtS7W1kN/7AbJ0HHqQ61L94hv5Vhu8oOkVRLo5fJj6IqXxavBG5TqIRrK +PGFLFWKW+uRF9bxierKgGoFmGruVPsYkSgIRpbbmdgggSGv3Y83JJ1JtsPQolwR Ja+JX9AeLEwqZfR6uY6kE6jBwRWJPGp2jjZ/d2RZkFdC66ce1f6Aw40hrVFM0vC8 nlIBBvYARZQz0pbAIt9IHSVUFZqcDTk6EM0/HdJ4yGdaPzSWnWSxvhi75/QmUD5K esx+cutrBxjACXFNxtSuDIB5Xj9rjqgvsdAq/8gX4dQaw2cusUunao5QFTaEFWtg aYVFO8l27oyHbt2tLRd7 =4/Vd -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
