Hi Chris, Thanks for the response.
On Fri, Mar 31, 2017 at 10:16 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----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. > > I got your point. Actually i meant both reusing connections and sessions both. But as we do not any symptom here, we will leave this for now. Thanks a lot for calrification on session timeout and using the same session for connections. > > 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. > Ok. > > > 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? > Yes, i will try to be more clear. So, the thing is my server with tomcat 7, has around 58 application deployed. There are 4-5 tools/applications that sends requests to my server. Suddenly the tomcat on all my test set ups stop responding and GUI/web access was slow and sluggish. I found tomcat memory was less than 100 mb, which is unusual then normal. So I am trying to find what consuming memory in tomcat. As Memory heap dump (i used eclipse memory analyzer tool) didn't helped much. I was wondering what is the reason of tomcat going bad. Or it is just i need to add more memory to heap from 1.2 G to 2.4? I am trying to see if jconsole will be helpful here. Any thoughts on debugging this. I alrady reviewed the localhost_Access logs to see all the requests and there response time and response size. Compared them to a working server. Not much of help yet. > > - -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 > >
