Hi Chris What makes you say that? Past cases, I saw where implementation or not using the JSESSION was making the connection over and over again for multiple transactions
What JVM are you using? We using Orcale JDK 1.7.0.131 Yes, 58 applications. On Thu, Mar 30, 2017 at 12:01 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > 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(InternalInputBuffer. > java:519) > > > > > at > > org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer. > java:504) > > > > > at > > org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Htt > p11Processor.java:168) > > > > > at > > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp1 > 1Processor.java:998) > > > > > at > > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(A > bstractProtocol.java:637) > > > > > at > > org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint > .java:318) > > > > > - - locked <0x8f1f68d8> (a org.apache.tomcat.util.net.SocketWrapper) > > at > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j > ava:1145) > > > > > at > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor. > java:615) > > > > > at > > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThr > 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 > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJY3VX/AAoJEBzwKT+lPKRY6yoP/1p46IDHftMpRIx2aUpdkTan > TCoiYtrwFGJ6o4WhPIVg7GNWv4p3aQr+Rkdtd1+b5ege2rAy75dB+to0CmvN8M1g > AxiXjQ5Ct1B6rP1LOGPrSZNM+3Urk0Gw8g50k1rMl/7/K79XqvA3bH2zjeSm4u/w > fY3veBg4Bru6nPCGmyUX+r8kfMOdIiNbiLDE2DDuBO7z4HLFms9Zd50XpcJw+e4J > rCpRRwqEI7RrhnaB5iASiUmKVUX6MCSQtAqHL6zHC+1nknj4rDAYHSuJsA/UoIuJ > Uuz6rlUfH9pZHf9iQ9Aw2K+zSjjW3QcsFkD/MUQs4sa/X80sXRKfWBkHvOl5IPjj > zzh/X5tlYFuHtkMHqRFx2jlX71geVa9TBbu/aOEG78AJSWNAEH97JHXQ9dKuB64P > VtyJAe3/Gtnelrb5kPrO7dN7bvQWwA/g2zQOlojZjP7MSLmBhd+Utvnustwa96ji > AsSrW9li19ld7Zi+SUbuBtvnFODoCAqx6OspBbCxyN9fd7RppKrf3G+stNzoPMPd > S/h+CxQXZxeGfPB7xTE6XEOz205cspqdH1CSwvKMDAdvQ449Y8njZdZQAcLxlSFL > +o8Cfx2g4fVta7UoBLPG+8sqmfAjsiur347tYMttFetlPkjZ6fydWkWO5ZDpD3hx > FFjHAakdd2RhL1jXZgaS > =LG2x > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
