tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Utkarsh Dave <utkarshkd...@gmail.com>
Subject Re: Ways to identify poorly designed client aplications sending request to Tomcat !
Date Sat, 01 Apr 2017 05:49:37 GMT
Hi Chris,

Thanks for the response.

On Fri, Mar 31, 2017 at 10:16 AM, Christopher Schultz <
chris@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 <
> > chris@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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message