Re: Error in stopping application tomcat !!
Hi Martin, These are the only two behaviors right now which I am getting on a regular basis. 1. During startup of the application and then shutdown 2. Running application and then shutdown. Please let me know if anything specific is further needed from my end which I can provide to have a better clarity. I have shared the server.xml and command which we are using in stopping the tomcat. On Thu, Jul 23, 2020 at 2:49 AM Martin Grigorov wrote: > On Wed, Jul 22, 2020, 15:55 Kushagra Bindal > wrote: > > > Hi Christopher, > > > > Did you get a chance to look into this? > > > > Please help us in resolving this issue. > > > > On Sat, Jul 18, 2020 at 11:26 AM Kushagra Bindal < > > bindal.kusha...@gmail.com> > > wrote: > > > > > Hi Chris, > > > > > > Additionally when trying to stop running application, we are getting > > below > > > error. > > > > > > Sat Jul 18 05:49:40 UTC 2020 > > > ** > > > * Stopping the Web Server > > > ** > > > Sat Jul 18 05:49:40 UTC 2020 > > > ./wfc: line 28: /usr/local/nginx/nginx: No such file or directory > > > ./wfc: line 233: /usr/local/nginx/nginx: No such file or directory > > > > > > Sat Jul 18 05:49:40 UTC 2020 > > > * Nginx has been stopped > > > ** > > > * Shutdown the wfc Server gracefully > > > ** > > > # * > > > # Tomcat shutdown with wait time: 30 > > > # * > > > Using CATALINA_BASE: /usr/local/xyz/tomcat > > > Using CATALINA_HOME: /usr/local/xyz/tomcat > > > Using CATALINA_TMPDIR: /usr/local/xyz/tomcat/temp > > > Using JRE_HOME:/usr/local/xyz/jdk > > > Using CLASSPATH: > > > > > > /usr/local/xyz/tomcat/bin/bootstrap.jar:/usr/local/xyz/tomcat/bin/tomcat-juli.jar > > > Using CATALINA_PID:/usr/local/xyz/tomcat/tomcat.pid > > > Tomcat did not stop in time. > > > To aid diagnostics a thread dump has been written to standard out. > > > > Anything interesting in this thread dump? > > > > Killing Tomcat with the PID: 4280 > > > The Tomcat process has been killed. > > > # * > > > # Tomcat shutdown result: 0 > > > # * > > > > > > > > > > > > Whereas below error that I mentioned earlier is coming when application > > is > > > in INPROGRESS and not yet come into running state and when we stop the > > same > > > it is throwing below error. > > > > > > On Sat, Jul 18, 2020 at 10:17 AM Kushagra Bindal < > > > bindal.kusha...@gmail.com> wrote: > > > > > >> Hi Chris, > > >> > > >> To stop tomcat we are using the below command. > > >> > > >> bin/shutdown.sh -$sleeptime -force > > >> > > >> Where in our case sleeptime is set to 30. > > >> > > >> Please find the attached server.xml which we are using in our > > application. > > >> > > >> Also I have copy-paste the complete content below in this email as > well. > > >> > > >> > > > > > >> > > >> > > >> > > >>> className="org.apache.catalina.startup.VersionLoggerListener" > > >> /> > > >>> >> SSLEngine="on" /> > > >>> >> className="org.apache.catalina.core.JreMemoryLeakPreventionListener" > /> > > >>> >> > className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" > > /> > > >>> >> className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" > > /> > > >> > > >> > >> type="org.apache.catalina.UserDatabase" > > >> description="User database that can be updated and > saved" > > >> > > >> factory="org.apache.catalina.users.MemoryUserDatabaseFactory" > > >> pathname="conf/tomcat-users.xml" /> > > >> > >> type="javax.sql.DataSource" > > >> username="db_username_stub" > > >> password="db_password_stub" > > >> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" > > >> url="READ_WRITE_URL_STUB" > > >> driverClassName="com.edb.Driver" > > >> initialSize="5" > > >> maxWait="3" > > >> maxActive="50" > > >> maxIdle="20" > > >> minIdle="5" > > >> maxAge="720" > > >> validationQuery="SELECT 1; COMMIT;" > > >> initSQL="ALTER SESSION SET statement_timeout=360; ALTER SESSION > SET > > >> idle_in_transaction_session_timeout=366; COMMIT;" > > >> poolPreparedStatements="true" > > >> testWhileIdle="false" > > >> testOnBorrow="true" > > >> testOnReturn="false" > > >> validationInterval="12" > > >> timeBetweenEvictionRunsMillis="15000" > > >> removeAbandonedTimeout="300" > > >> rem
Re: Error in stopping application tomcat !!
On Wed, Jul 22, 2020, 15:55 Kushagra Bindal wrote: > Hi Christopher, > > Did you get a chance to look into this? > > Please help us in resolving this issue. > > On Sat, Jul 18, 2020 at 11:26 AM Kushagra Bindal < > bindal.kusha...@gmail.com> > wrote: > > > Hi Chris, > > > > Additionally when trying to stop running application, we are getting > below > > error. > > > > Sat Jul 18 05:49:40 UTC 2020 > > ** > > * Stopping the Web Server > > ** > > Sat Jul 18 05:49:40 UTC 2020 > > ./wfc: line 28: /usr/local/nginx/nginx: No such file or directory > > ./wfc: line 233: /usr/local/nginx/nginx: No such file or directory > > > > Sat Jul 18 05:49:40 UTC 2020 > > * Nginx has been stopped > > ** > > * Shutdown the wfc Server gracefully > > ** > > # * > > # Tomcat shutdown with wait time: 30 > > # * > > Using CATALINA_BASE: /usr/local/xyz/tomcat > > Using CATALINA_HOME: /usr/local/xyz/tomcat > > Using CATALINA_TMPDIR: /usr/local/xyz/tomcat/temp > > Using JRE_HOME:/usr/local/xyz/jdk > > Using CLASSPATH: > > > /usr/local/xyz/tomcat/bin/bootstrap.jar:/usr/local/xyz/tomcat/bin/tomcat-juli.jar > > Using CATALINA_PID:/usr/local/xyz/tomcat/tomcat.pid > > Tomcat did not stop in time. > > To aid diagnostics a thread dump has been written to standard out. > Anything interesting in this thread dump? > Killing Tomcat with the PID: 4280 > > The Tomcat process has been killed. > > # * > > # Tomcat shutdown result: 0 > > # * > > > > > > > > Whereas below error that I mentioned earlier is coming when application > is > > in INPROGRESS and not yet come into running state and when we stop the > same > > it is throwing below error. > > > > On Sat, Jul 18, 2020 at 10:17 AM Kushagra Bindal < > > bindal.kusha...@gmail.com> wrote: > > > >> Hi Chris, > >> > >> To stop tomcat we are using the below command. > >> > >> bin/shutdown.sh -$sleeptime -force > >> > >> Where in our case sleeptime is set to 30. > >> > >> Please find the attached server.xml which we are using in our > application. > >> > >> Also I have copy-paste the complete content below in this email as well. > >> > >> > > >> > >> > >> > >>className="org.apache.catalina.startup.VersionLoggerListener" > >> /> > >>>> SSLEngine="on" /> > >>>> className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /> > >>>> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" > /> > >>>> className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" > /> > >> > >> >> type="org.apache.catalina.UserDatabase" > >> description="User database that can be updated and saved" > >> > >> factory="org.apache.catalina.users.MemoryUserDatabaseFactory" > >> pathname="conf/tomcat-users.xml" /> > >> >> type="javax.sql.DataSource" > >> username="db_username_stub" > >> password="db_password_stub" > >> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" > >> url="READ_WRITE_URL_STUB" > >> driverClassName="com.edb.Driver" > >> initialSize="5" > >> maxWait="3" > >> maxActive="50" > >> maxIdle="20" > >> minIdle="5" > >> maxAge="720" > >> validationQuery="SELECT 1; COMMIT;" > >> initSQL="ALTER SESSION SET statement_timeout=360; ALTER SESSION SET > >> idle_in_transaction_session_timeout=366; COMMIT;" > >> poolPreparedStatements="true" > >> testWhileIdle="false" > >> testOnBorrow="true" > >> testOnReturn="false" > >> validationInterval="12" > >> timeBetweenEvictionRunsMillis="15000" > >> removeAbandonedTimeout="300" > >> removeAbandoned="false" > >> logAbandoned="false" > >> minEvictableIdleTimeMillis="12" > >> jmxEnabled="true" > >> > >> > jdbcInterceptors="org.apache.tomcat.jdbc.pool.interceptor.ConnectionState; > >> > >> org.apache.tomcat.jdbc.pool.interceptor.StatementFinalizer; > >> > >> org.apache.tomcat.jdbc.pool.interceptor.StatementCache(max=4000)" /> > >> >> type="javax.sql.DataSource" > >> username="db_username_stub" > >> password="db_password_stub" > >> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" > >> url="READ_ONLY_URL_STUB" > >> driverClassName="com.edb.Driver" > >>
Re: Memory leak in the PKCS11 how to fix the problem
On Wed, Jul 22, 2020, 16:58 Ragavendhiran Bhiman (rabhiman) wrote: > Sorry Martin, > > My answers are inline. > Take a heap dump and analyze it! > Thanks & Regards, > Raghav > > On 22/07/20, 7:20 PM, "Ragavendhiran Bhiman (rabhiman)" > wrote: > > Hello Martin, > > Thanks for your reply > > > https://www.dropbox.com/sh/o6zra7pf2o1xpge/AAA1J7BaVdPDF7s3RjPmy0xBa?dl=0 > > Here is the link I have shared the flame graph. > Also kindly check my answers in red as well. > > Thanks & Regards, > Raghav > > > On 22/07/20, 2:33 PM, "Martin Grigorov" wrote: > > Hi Ragavendhiran, > > On Sat, Jul 18, 2020 at 3:55 PM Ragavendhiran Bhiman (rabhiman) > wrote: > > > Hello All, > > > > > > > > I am seeing the memory leaks from tomcat apache in the following > SSL path > > using PKCS11. Attached the flame graph of memory possible memory > leaks in > > this area. > > > > Please check the attached flame graph of the memory trace. On > simply a > > long run the memory keep on allocated in these back traces only > causing the > > memory leak, and the polling of the async profiler for more than > 6hours > > shows this clearly. Could you please help how to fix this > problem? > > > > (open this svg graph in browser only) > > > > > > > > Note: If C_DestroyObject is not called because of finalizer > accumulation > > is also tested by inducing the gc using the jmap command still > could see > > the memory never gone down after the Full GC collection as well. > Expecting > > your advice on the same. > > > > With AsyncProfiler '-e alloc' you can see what part of the code is > responsible for making most of the memory allocations, but it > doesn't tell > you whether those objects leak or not. AsyncProfiler helps you to > identify > the top allocations and if you manage to reduce them then you will > reduce > the GC runs and the time they take. > To debug memory leaks you need to take a heap dump, e.g. with 'jmap > -dump:live,format=b,file=heap.bin ' and analyze it. I'd > recommend you > to use Eclipse MAT to do that. > > "Yes with async profiler and just leaving the server without > any sequence of action the memory started growing (RSS grows) when I > profiled during that sequence there is no other memory allocation happening > except this one. > That’s why I am suspecting this flow clearly. Samples are only through > this flow only". > > Also in your flame graph I see that Netty is responsible for > 49.04% of > the allocated objects and Tomcat for just 25.32%. > > > > > > Regards, > > > > Raghav > > > > Infrastructure engineer, > > > > Cisco ISE. > > > > > > > > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > >
Re: Why does Tomcat 8.0.36 compile huge JSPs fine but precompiling JSPs with jspc + javac fails with 'code too large' error? And how to fix it?
> On Wed, Jul 22, 2020 at 6:58 PM Mark Thomas wrote: >> On 22/07/2020 15:49, Максим Фастовец wrote: >> Please advise where do I get that Eclipse Compiler for Java? > It is ecj-*.jar in $CATALINA_HOME/lib in your Tomcat installation. Cold you also please tell how to run it via ant? How to define such an ant task? Maks
Re: Why does Tomcat 8.0.36 compile huge JSPs fine but precompiling JSPs with jspc + javac fails with 'code too large' error? And how to fix it?
Thank you!
Re: Why does Tomcat 8.0.36 compile huge JSPs fine but precompiling JSPs with jspc + javac fails with 'code too large' error? And how to fix it?
On 22/07/2020 15:49, Максим Фастовец wrote: >> On Wed, Jul 22, 2020 at 3:32 PM Mark Thomas wrote: >>> On 22/07/2020 13:01, Максим Фастовец wrote: >>> Can you please tell why Tomcat 8.0.36 compiles huge JSPs fine but >>> precompiling JSPs with jspc + javac fails with code too large error? And >>> how to fix it? Thank you! >> >> Possibly because Tomcat doesn't use javac to compile JSPs. At least not >> by default. It uses the Eclipse Compiler for Java. > > Thank you for your reply. > Please advise where do I get that Eclipse Compiler for Java? Cannot find > it via google. It is ecj-*.jar in $CATALINA_HOME/lib in your Tomcat installation. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does Tomcat 8.0.36 compile huge JSPs fine but precompiling JSPs with jspc + javac fails with 'code too large' error? And how to fix it?
Hi Максим, try there: https://mvnrepository.com/artifact/org.eclipse.jdt.core.compiler/ecj Em qua., 22 de jul. de 2020 às 12:07, Максим Фастовец escreveu: > > On Wed, Jul 22, 2020 at 3:32 PM Mark Thomas wrote: > >> On 22/07/2020 13:01, Максим Фастовец wrote: > >> Can you please tell why Tomcat 8.0.36 compiles huge JSPs fine but > >> precompiling JSPs with jspc + javac fails with code too large error? And > >> how to fix it? Thank you! > > > > Possibly because Tomcat doesn't use javac to compile JSPs. At least not > > by default. It uses the Eclipse Compiler for Java. > > Thank you for your reply. > Please advise where do I get that Eclipse Compiler for Java? Cannot find > it via google. > > Maks > -- https://sombriks.com.br
Re: Rewrite Valve Problem
Thanks to the both of you for the help On Wed, Jul 22, 2020 at 4:46 AM Martin Grigorov wrote: > Hi Jerry, > > On Tue, Jul 21, 2020 at 2:39 AM Jerry Malcolm > wrote: > > > > > On 7/20/2020 5:00 PM, Mark Thomas wrote: > > > On 20/07/2020 22:43, Jerry Malcolm wrote: > > > > > > > > > > > >>> Do you have a ROOT web application deployed? If not, this could be > > >>> https://bz.apache.org/bugzilla/show_bug.cgi?id=64593 > > >> Mark, I do not have a root context. So that very likely is the > > >> problem. Not 100% sure why the thought is that there should always > be a > > >> root context. But I'm sure there are good reasons. Easy enough to > > >> create one. I'll let you know. > > > Generally, I'd expect to see a ROOT context so there is something there > > > to handle requests that don't map to any other context. It is easier to > > > deploy custom 404 error pages if you have a ROOT context for example. > > > > > > That said, it isn't necessary and we do treat stuff not working without > > > a ROOT context as a bug. > > > > > > All you need to fix BZ 64593 is a directory called ROOT in webapps. > > > > Wow. 4 little letters I've been using TC for over 15 years without > > a ROOT. Probably because I never routed anything through mod_jk that > > didn't match a known context. I have no problem if you want to treat > > not having a ROOT context as a bug, But please give an error message > > > > As explained earlier by Mark this was a bug and it is fixed for the next > release. > Using a dummy ROOT folder is a workaround until the next release. > > > > in startup and/or provide an error message if/when rewrite valve fails > > because there is no ROOT context defined. Thank you for explaining > > what's happening. There is not a chance I would have correlated my > > symptoms in 100 years to not having a ROOT context. I really do > > appreciate the help. All working now > > > > Jerry > > > > > Mark > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > -- Kenneth Noel Boston College DBA (617) 552-8511
Re: Why does Tomcat 8.0.36 compile huge JSPs fine but precompiling JSPs with jspc + javac fails with 'code too large' error? And how to fix it?
> On Wed, Jul 22, 2020 at 3:32 PM Mark Thomas wrote: >> On 22/07/2020 13:01, Максим Фастовец wrote: >> Can you please tell why Tomcat 8.0.36 compiles huge JSPs fine but >> precompiling JSPs with jspc + javac fails with code too large error? And >> how to fix it? Thank you! > > Possibly because Tomcat doesn't use javac to compile JSPs. At least not > by default. It uses the Eclipse Compiler for Java. Thank you for your reply. Please advise where do I get that Eclipse Compiler for Java? Cannot find it via google. Maks
Re: Memory leak in the PKCS11 how to fix the problem
The tomcat version is apache-tomcat-8.5.29 And RedHat Enterprise Linux 7.6 On 22/07/20, 7:28 PM, "Ragavendhiran Bhiman (rabhiman)" wrote: Hi Chris, Please see my answers inline. Also shared the svg graph here. https://www.dropbox.com/sh/o6zra7pf2o1xpge/AAA1J7BaVdPDF7s3RjPmy0xBa?dl=0 Kindly reply. Thanks & Regards, Raghav On 20/07/20, 11:08 PM, "Christopher Schultz" wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ragavendhiran, On 7/18/20 08:53, Ragavendhiran Bhiman (rabhiman) wrote: > The OS is RHEL => 7.6 > > > From: "Ragavendhiran Bhiman (rabhiman)" Date: > Saturday, 18 July 2020 at 6:21 PM To: Tomcat Users List > Subject: Memory leak in the PKCS11 how to > fix the problem > > > > From: "Ragavendhiran Bhiman (rabhiman)" Date: > Saturday, 18 July 2020 at 6:20 PM To: Tomcat Users List > Subject: Memory leak in the PKCS11 how to > fix the problem > > Hello All, > > I am seeing the memory leaks from tomcat apache in the following > SSL path using PKCS11. In what way are you using PKCS#11? Using a hardware crypto engine via OpenSSL? Are you using the APR connector or are you using OpenSSL via JSSE? It is being used via the OpenSSL. I am not sure how to identify it is via the APR or hardware. > Attached the flame graph of memory possible memory leaks in this > area. Please check the attached flame graph of the memory trace. Attachments are stripped from messages to this list. Can you post the graph somewhere and include a link to a reply here? Attached again using the dropbox. > On simply a long run the memory keep on allocated in these back > traces only causing the memory leak, and the polling of the async > profiler for more than 6hours shows this clearly. Could you please > help how to fix this problem? (open this svg graph in browser > only)> Note: If C_DestroyObject is not called because of finalizer > accumulation is also tested by inducing the gc using the jmap > command still could see the memory never gone down after the Full > GC collection as well. Expecting your advice on the same. Are you suggesting that the solution will be to do something explicit in a class finalizer? Or are you suggesting that some additional native calls are required to clean-up. I called the GC via jmap -histo:live but still the weak references not cleaned up the RSS never reduced. This means that some where the memory being held in native that’s what my suspect. Kindly suggest from your side as well. Thanks. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8V1jYACgkQHPApP6U8 pFj3Rw/7B9SxlYNFPZoM6O4GWnwlxI2u+tLrsk2x/6TNOQuFnOIACctTKVe/WIwI /kF3O7kqwfDEewDhNa6KndUpQgWcvrtbON/QXEAK8SE7HaP0uZv0n5fB6FyRNPPo uJpnVu5WkJuvFcc9VmluMk9y+SdijhucQtIiK8Y+JEeHmp3Jjg3b45TeJYupDG3K iAuKqjgWHdRwpVgUNIKxj27PJJBs+qG8yfg7qkVvHrJHzNvZv5rGImcjtwPO6ktQ U7yWIcJLldF4pkOAWGSiqaCbZsFUCVRK8euejAj5kThZRELKtrJq+QOCy+pIiYHe rvJpJyG44VLYMqYDMPkDrHVrSJIj88zSJNdfBWXvnC2Ol7dJRTfpau19Js/kYwls 53cELUg7XNOLpH14KnAKk2XMh25xjuZTHLtj2G3p61Frb48+81Ns6X8Hh/oDt/n+ vGUpwU1Crf2HuXg1YiF4L3aw6UnnS3vH/BeeZpj6z8qwFdw9O7ylAcXOndhAiyN0 SxQYmJIXkL8+WXBSTWt7dWZBdYiml/Zl2lkDhRGh+ftCCYZ8UgK5d2+b2HHVQiot nEs/dAu8rESBkFe0zXB9fgSeviLNwBDkAvenFJ/kZMstT5tzFZiLZW4EKpB8OWTx fbOGK5KQZB37Cbv+Eq64axWEK3vQHYROfeeAzEz3NgmYE2w74Rg= =yShM -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org ?B�CB�?�?[��X��ܚX�K??K[XZ[?�?\�\��][��X��ܚX�P??�X�]?�\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[�?�??K[XZ[?�?\�\��Z?[�X�]?�\?X�?K�ܙ�B�
Re: Classloading Behavior in Embedded Tomcat
I tried that with standalone Tomcat and it works. I can deploy Jersey-1 and Jersey-2 apps together. I was wondering whether Loader with delegate=false work in context for embedded? Thanks Chirag On Wed, 22 Jul, 2020, 5:03 pm Mark Thomas, wrote: > On 22/07/2020 11:35, Chirag Dewan wrote: > > Thanks for a very quick reply Mark. > > > > The Tomcat version is 8.5.46. > > > > Though I do plan to upgrade to 9.0.36 in the coming weeks. > > OK. Both behave the same way which makes things easier. > > See the source code for full details but the summary is: > > First Tomcat checks if the requested class is available from the same > class loader that loaded java.lang.String. If it is, it loads it from > that class loader. This prevents web applications over-ridding Java SE > classes. > > If the class has not been loaded yet, Tomcat then checks to see if it is > a class that Tomcat is expected to provide. If it is, it uses the common > class loader to load it. > > If the class isn't loaded the following search order is used: > - WEB-INF/classes > - WEB-INF/lib > - $CATALINA_BASE/lib (for classes) > - $CATALINA_BASE/lib (for JARs) > - bootstrap / classpath > > Embedded scenarios tend not to set up the same class loader structure as > stand alone Tomcat. Often, they use a single class loader for > everything. I'd check that your scenario works in a stand alone Tomcat > first and once you have that working, transfer it to embedded with > particular attention to class loader configuration. > > Mark > > > > > > Chirag > > > > On Wed, 22 Jul, 2020, 4:03 pm Mark Thomas, wrote: > > > >> On 22/07/2020 11:18, Chirag Dewan wrote: > >>> Hi, > >>> > >>> Due to some backward compatibility concerns, I need to support both > >>> Jersey-1 and Jersey-2 on the same Tomcat instance. This is an embedded > >>> tomcat which runs inside a JVM application. > >>> > >>> Since, Jersey-1 and Jersey-2 have different JAXRS versions, I tried to > >>> remove both jsr311 and javax.ws.rs-2 from my JVMs classpath. And > instead > >>> packaged these in the WAR/WEB-INF\lib along with jersey version > specific > >>> jars like jersey-core-1.x, jersey-common-2.x etc. > >>> > >>> Now when I start my Jersey-1 application, it couldn't find > >>> javax.ws.rs.ext.MessageBodyReader. > >>> > >>> I read Classloader HOW-TO and although it says that the order of > loading > >>> JavaEE classes is bootstrap first, it never says anything about WEB-INF > >> as > >>> a source for these jars. > >>> > >>> So if there any way I can load javax.* classes from WEB-INF\lib? > >> > >> Tomcat version? > >> > >> Different Tomcat versions have taken different approaches to > >> implementing this requirement. A recent(ish) implementation should be > >> fine but with the exact version number we can give a better answer. > >> > >> Mark > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Memory leak in the PKCS11 how to fix the problem
Hi Chris, Please see my answers inline. Also shared the svg graph here. https://www.dropbox.com/sh/o6zra7pf2o1xpge/AAA1J7BaVdPDF7s3RjPmy0xBa?dl=0 Kindly reply. Thanks & Regards, Raghav On 20/07/20, 11:08 PM, "Christopher Schultz" wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ragavendhiran, On 7/18/20 08:53, Ragavendhiran Bhiman (rabhiman) wrote: > The OS is RHEL => 7.6 > > > From: "Ragavendhiran Bhiman (rabhiman)" Date: > Saturday, 18 July 2020 at 6:21 PM To: Tomcat Users List > Subject: Memory leak in the PKCS11 how to > fix the problem > > > > From: "Ragavendhiran Bhiman (rabhiman)" Date: > Saturday, 18 July 2020 at 6:20 PM To: Tomcat Users List > Subject: Memory leak in the PKCS11 how to > fix the problem > > Hello All, > > I am seeing the memory leaks from tomcat apache in the following > SSL path using PKCS11. In what way are you using PKCS#11? Using a hardware crypto engine via OpenSSL? Are you using the APR connector or are you using OpenSSL via JSSE? It is being used via the OpenSSL. I am not sure how to identify it is via the APR or hardware. > Attached the flame graph of memory possible memory leaks in this > area. Please check the attached flame graph of the memory trace. Attachments are stripped from messages to this list. Can you post the graph somewhere and include a link to a reply here? Attached again using the dropbox. > On simply a long run the memory keep on allocated in these back > traces only causing the memory leak, and the polling of the async > profiler for more than 6hours shows this clearly. Could you please > help how to fix this problem? (open this svg graph in browser > only)> Note: If C_DestroyObject is not called because of finalizer > accumulation is also tested by inducing the gc using the jmap > command still could see the memory never gone down after the Full > GC collection as well. Expecting your advice on the same. Are you suggesting that the solution will be to do something explicit in a class finalizer? Or are you suggesting that some additional native calls are required to clean-up. I called the GC via jmap -histo:live but still the weak references not cleaned up the RSS never reduced. This means that some where the memory being held in native that’s what my suspect. Kindly suggest from your side as well. Thanks. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8V1jYACgkQHPApP6U8 pFj3Rw/7B9SxlYNFPZoM6O4GWnwlxI2u+tLrsk2x/6TNOQuFnOIACctTKVe/WIwI /kF3O7kqwfDEewDhNa6KndUpQgWcvrtbON/QXEAK8SE7HaP0uZv0n5fB6FyRNPPo uJpnVu5WkJuvFcc9VmluMk9y+SdijhucQtIiK8Y+JEeHmp3Jjg3b45TeJYupDG3K iAuKqjgWHdRwpVgUNIKxj27PJJBs+qG8yfg7qkVvHrJHzNvZv5rGImcjtwPO6ktQ U7yWIcJLldF4pkOAWGSiqaCbZsFUCVRK8euejAj5kThZRELKtrJq+QOCy+pIiYHe rvJpJyG44VLYMqYDMPkDrHVrSJIj88zSJNdfBWXvnC2Ol7dJRTfpau19Js/kYwls 53cELUg7XNOLpH14KnAKk2XMh25xjuZTHLtj2G3p61Frb48+81Ns6X8Hh/oDt/n+ vGUpwU1Crf2HuXg1YiF4L3aw6UnnS3vH/BeeZpj6z8qwFdw9O7ylAcXOndhAiyN0 SxQYmJIXkL8+WXBSTWt7dWZBdYiml/Zl2lkDhRGh+ftCCYZ8UgK5d2+b2HHVQiot nEs/dAu8rESBkFe0zXB9fgSeviLNwBDkAvenFJ/kZMstT5tzFZiLZW4EKpB8OWTx fbOGK5KQZB37Cbv+Eq64axWEK3vQHYROfeeAzEz3NgmYE2w74Rg= =yShM -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Memory leak in the PKCS11 how to fix the problem
Sorry Martin, My answers are inline. Thanks & Regards, Raghav On 22/07/20, 7:20 PM, "Ragavendhiran Bhiman (rabhiman)" wrote: Hello Martin, Thanks for your reply https://www.dropbox.com/sh/o6zra7pf2o1xpge/AAA1J7BaVdPDF7s3RjPmy0xBa?dl=0 Here is the link I have shared the flame graph. Also kindly check my answers in red as well. Thanks & Regards, Raghav On 22/07/20, 2:33 PM, "Martin Grigorov" wrote: Hi Ragavendhiran, On Sat, Jul 18, 2020 at 3:55 PM Ragavendhiran Bhiman (rabhiman) wrote: > Hello All, > > > > I am seeing the memory leaks from tomcat apache in the following SSL path > using PKCS11. Attached the flame graph of memory possible memory leaks in > this area. > > Please check the attached flame graph of the memory trace. On simply a > long run the memory keep on allocated in these back traces only causing the > memory leak, and the polling of the async profiler for more than 6hours > shows this clearly. Could you please help how to fix this problem? > > (open this svg graph in browser only) > > > > Note: If C_DestroyObject is not called because of finalizer accumulation > is also tested by inducing the gc using the jmap command still could see > the memory never gone down after the Full GC collection as well. Expecting > your advice on the same. > With AsyncProfiler '-e alloc' you can see what part of the code is responsible for making most of the memory allocations, but it doesn't tell you whether those objects leak or not. AsyncProfiler helps you to identify the top allocations and if you manage to reduce them then you will reduce the GC runs and the time they take. To debug memory leaks you need to take a heap dump, e.g. with 'jmap -dump:live,format=b,file=heap.bin ' and analyze it. I'd recommend you to use Eclipse MAT to do that. "Yes with async profiler and just leaving the server without any sequence of action the memory started growing (RSS grows) when I profiled during that sequence there is no other memory allocation happening except this one. That’s why I am suspecting this flow clearly. Samples are only through this flow only". Also in your flame graph I see that Netty is responsible for 49.04% of the allocated objects and Tomcat for just 25.32%. > > Regards, > > Raghav > > Infrastructure engineer, > > Cisco ISE. > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Memory leak in the PKCS11 how to fix the problem
Hello Martin, Thanks for your reply https://www.dropbox.com/sh/o6zra7pf2o1xpge/AAA1J7BaVdPDF7s3RjPmy0xBa?dl=0 Here is the link I have shared the flame graph. Also kindly check my answers in red as well. Thanks & Regards, Raghav On 22/07/20, 2:33 PM, "Martin Grigorov" wrote: Hi Ragavendhiran, On Sat, Jul 18, 2020 at 3:55 PM Ragavendhiran Bhiman (rabhiman) wrote: > Hello All, > > > > I am seeing the memory leaks from tomcat apache in the following SSL path > using PKCS11. Attached the flame graph of memory possible memory leaks in > this area. > > Please check the attached flame graph of the memory trace. On simply a > long run the memory keep on allocated in these back traces only causing the > memory leak, and the polling of the async profiler for more than 6hours > shows this clearly. Could you please help how to fix this problem? > > (open this svg graph in browser only) > > > > Note: If C_DestroyObject is not called because of finalizer accumulation > is also tested by inducing the gc using the jmap command still could see > the memory never gone down after the Full GC collection as well. Expecting > your advice on the same. > With AsyncProfiler '-e alloc' you can see what part of the code is responsible for making most of the memory allocations, but it doesn't tell you whether those objects leak or not. AsyncProfiler helps you to identify the top allocations and if you manage to reduce them then you will reduce the GC runs and the time they take. To debug memory leaks you need to take a heap dump, e.g. with 'jmap -dump:live,format=b,file=heap.bin ' and analyze it. I'd recommend you to use Eclipse MAT to do that. "Yes with async profiler and just leaving the server without any sequence of action the memory started growing (RSS grows) when I profiled during that sequence there is no other memory allocation happening except this one. That’s why I am suspecting this flow clearly. Samples are only through this flow only". Also in your flame graph I see that Netty is responsible for 49.04% of the allocated objects and Tomcat for just 25.32%. > > Regards, > > Raghav > > Infrastructure engineer, > > Cisco ISE. > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Error in stopping application tomcat !!
Hi Christopher, Did you get a chance to look into this? Please help us in resolving this issue. On Sat, Jul 18, 2020 at 11:26 AM Kushagra Bindal wrote: > Hi Chris, > > Additionally when trying to stop running application, we are getting below > error. > > Sat Jul 18 05:49:40 UTC 2020 > ** > * Stopping the Web Server > ** > Sat Jul 18 05:49:40 UTC 2020 > ./wfc: line 28: /usr/local/nginx/nginx: No such file or directory > ./wfc: line 233: /usr/local/nginx/nginx: No such file or directory > > Sat Jul 18 05:49:40 UTC 2020 > * Nginx has been stopped > ** > * Shutdown the wfc Server gracefully > ** > # * > # Tomcat shutdown with wait time: 30 > # * > Using CATALINA_BASE: /usr/local/xyz/tomcat > Using CATALINA_HOME: /usr/local/xyz/tomcat > Using CATALINA_TMPDIR: /usr/local/xyz/tomcat/temp > Using JRE_HOME:/usr/local/xyz/jdk > Using CLASSPATH: > /usr/local/xyz/tomcat/bin/bootstrap.jar:/usr/local/xyz/tomcat/bin/tomcat-juli.jar > Using CATALINA_PID:/usr/local/xyz/tomcat/tomcat.pid > Tomcat did not stop in time. > To aid diagnostics a thread dump has been written to standard out. > Killing Tomcat with the PID: 4280 > The Tomcat process has been killed. > # * > # Tomcat shutdown result: 0 > # * > > > > Whereas below error that I mentioned earlier is coming when application is > in INPROGRESS and not yet come into running state and when we stop the same > it is throwing below error. > > On Sat, Jul 18, 2020 at 10:17 AM Kushagra Bindal < > bindal.kusha...@gmail.com> wrote: > >> Hi Chris, >> >> To stop tomcat we are using the below command. >> >> bin/shutdown.sh -$sleeptime -force >> >> Where in our case sleeptime is set to 30. >> >> Please find the attached server.xml which we are using in our application. >> >> Also I have copy-paste the complete content below in this email as well. >> >> >> >> >> >> > /> >> > SSLEngine="on" /> >> > className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /> >> > className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /> >> > className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" /> >> >> > type="org.apache.catalina.UserDatabase" >> description="User database that can be updated and saved" >> >> factory="org.apache.catalina.users.MemoryUserDatabaseFactory" >> pathname="conf/tomcat-users.xml" /> >> > type="javax.sql.DataSource" >> username="db_username_stub" >> password="db_password_stub" >> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" >> url="READ_WRITE_URL_STUB" >> driverClassName="com.edb.Driver" >> initialSize="5" >> maxWait="3" >> maxActive="50" >> maxIdle="20" >> minIdle="5" >> maxAge="720" >> validationQuery="SELECT 1; COMMIT;" >> initSQL="ALTER SESSION SET statement_timeout=360; ALTER SESSION SET >> idle_in_transaction_session_timeout=366; COMMIT;" >> poolPreparedStatements="true" >> testWhileIdle="false" >> testOnBorrow="true" >> testOnReturn="false" >> validationInterval="12" >> timeBetweenEvictionRunsMillis="15000" >> removeAbandonedTimeout="300" >> removeAbandoned="false" >> logAbandoned="false" >> minEvictableIdleTimeMillis="12" >> jmxEnabled="true" >> >> jdbcInterceptors="org.apache.tomcat.jdbc.pool.interceptor.ConnectionState; >> >> org.apache.tomcat.jdbc.pool.interceptor.StatementFinalizer; >> >> org.apache.tomcat.jdbc.pool.interceptor.StatementCache(max=4000)" /> >> > type="javax.sql.DataSource" >> username="db_username_stub" >> password="db_password_stub" >> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" >> url="READ_ONLY_URL_STUB" >> driverClassName="com.edb.Driver" >> initialSize="5" >> maxWait="3" >> maxActive="50" >> maxIdle="20" >> minIdle="5" >> defaultReadOnly="true" >> validationQuery="SELECT 1; COMMIT;" >> initSQL="ALTER SESSION SET statement_timeout=360; ALTER >> SESSION SET idle_in_transaction_session_timeout=366; COMMIT;" >> poolPreparedStatements="true" >> testWhileId
Re: Why does Tomcat 8.0.36 compile huge JSPs fine but precompiling JSPs with jspc + javac fails with 'code too large' error? And how to fix it?
On 22/07/2020 13:01, Максим Фастовец wrote:
> Hi!
>
> We're working on moving an old legacy Servlet/JSP web app from WebSphere to
> Tomcat to cut our expenses. I figured out that the latest version of Tomcat
> where our web app runs without 'The code of method
> _jspService(HttpServletRequest, HttpServletResponse) is exceeding the 65535
> bytes limit' error is 8.0.36. I also needed to tune some init-params in
> ${TOMCAT8.0.36.HOME}/conf/web.xml for JspServlet section:
>
>
>mappedfile
>false
>
>
>classdebuginfo
>false
>
>
>displaySourceFragment
>false
>
>
>dumpSmap
>false
>
>
>suppressSmap
>true
>
>
>trimSpaces
>true
>
>
> I also figured out that it is jasper.jar and jasper-el.jar which somehow
> serve to precompile JSPs. So if I replace $TOMCAT9_HOME/lib/jasper.jar and
> $TOMCAT9_HOME/lib/jasper-el.jar with $TOMCAT8.0.36_HOME/lib/jasper.jar and
> $TOMCAT8.0.36_HOME/lib/jasper-el.jar respectively I'll get our legacy web
> app running on Tomcat 9 as well without that '64k bytes limit' error.
Unlikely.
What you will get is a completely unsupported configuration that may
exhibit subtle bugs that you will have sole responsibility for fixing.
If you really want to go that route and you are happy that it works for
you then, fair enough, that is your choice. But if you go down that
route you are entirely on your own.
> But when I follow this suggestion to precompile JSPs using Tomcat 8.0.36
> distr dir as ${tomcat.home} I am getting 'error: code too large public
> void _jspService(final javax.servlet.http.HttpServletRequest request, final
> javax.servlet.http.HttpServletResponse response)' error. I added all the
> init-params to jasper ant task I added to JspServlet section in
> ${TOMCAT8.0.36.HOME}/conf/web.xml but still precompilation fails
>
>validateXml="false"
> mappedFile="false"
> smapDumped="false"
> smapSuppressed="true"
> trimSpaces="true"
> classdebuginfo="false"
> uriroot="${webapp.path}"
> failOnError="false"
> webXmlFragment="${webapp.path}/WEB-INF/generated_web.xml"
> outputDir="${webapp.path}/WEB-INF/src" />
>
> I also tried running the task without 'compiler' attribute and
> changing 'compiler' attribute to all possible values mentioned here:
> https://ant.apache.org/manual/Tasks/javac.html#compilervalues but looks
> like it doesn't affect the task at all.
>
> I tried it with ant 1.9.15 and with 1.9.7 and still got that 'code too
> large' error.
>
> Can you please tell why Tomcat 8.0.36 compiles huge JSPs fine but
> precompiling JSPs with jspc + javac fails with code too large error? And
> how to fix it? Thank you!
Possibly because Tomcat doesn't use javac to compile JSPs. At least not
by default. It uses the Eclipse Compiler for Java.
I suspect your time would be better spent refactoring the JSPs that are
currently exceeding the 64k limit and then running on a supported
configuration.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Why does Tomcat 8.0.36 compile huge JSPs fine but precompiling JSPs with jspc + javac fails with 'code too large' error? And how to fix it?
Hi!
We're working on moving an old legacy Servlet/JSP web app from WebSphere to
Tomcat to cut our expenses. I figured out that the latest version of Tomcat
where our web app runs without 'The code of method
_jspService(HttpServletRequest, HttpServletResponse) is exceeding the 65535
bytes limit' error is 8.0.36. I also needed to tune some init-params in
${TOMCAT8.0.36.HOME}/conf/web.xml for JspServlet section:
mappedfile
false
classdebuginfo
false
displaySourceFragment
false
dumpSmap
false
suppressSmap
true
trimSpaces
true
I also figured out that it is jasper.jar and jasper-el.jar which somehow
serve to precompile JSPs. So if I replace $TOMCAT9_HOME/lib/jasper.jar and
$TOMCAT9_HOME/lib/jasper-el.jar with $TOMCAT8.0.36_HOME/lib/jasper.jar and
$TOMCAT8.0.36_HOME/lib/jasper-el.jar respectively I'll get our legacy web
app running on Tomcat 9 as well without that '64k bytes limit' error.
But when I follow this suggestion to precompile JSPs using Tomcat 8.0.36
distr dir as ${tomcat.home} I am getting 'error: code too large public
void _jspService(final javax.servlet.http.HttpServletRequest request, final
javax.servlet.http.HttpServletResponse response)' error. I added all the
init-params to jasper ant task I added to JspServlet section in
${TOMCAT8.0.36.HOME}/conf/web.xml but still precompilation fails
I also tried running the task without 'compiler' attribute and
changing 'compiler' attribute to all possible values mentioned here:
https://ant.apache.org/manual/Tasks/javac.html#compilervalues but looks
like it doesn't affect the task at all.
I tried it with ant 1.9.15 and with 1.9.7 and still got that 'code too
large' error.
Can you please tell why Tomcat 8.0.36 compiles huge JSPs fine but
precompiling JSPs with jspc + javac fails with code too large error? And
how to fix it? Thank you!
I also raised this question on StackOverflow but still haven't got any
answers: https://stackoverflow.com/q/62955156/6807541
Kind Regards,
Maks.
Re: Classloading Behavior in Embedded Tomcat
On 22/07/2020 11:35, Chirag Dewan wrote: > Thanks for a very quick reply Mark. > > The Tomcat version is 8.5.46. > > Though I do plan to upgrade to 9.0.36 in the coming weeks. OK. Both behave the same way which makes things easier. See the source code for full details but the summary is: First Tomcat checks if the requested class is available from the same class loader that loaded java.lang.String. If it is, it loads it from that class loader. This prevents web applications over-ridding Java SE classes. If the class has not been loaded yet, Tomcat then checks to see if it is a class that Tomcat is expected to provide. If it is, it uses the common class loader to load it. If the class isn't loaded the following search order is used: - WEB-INF/classes - WEB-INF/lib - $CATALINA_BASE/lib (for classes) - $CATALINA_BASE/lib (for JARs) - bootstrap / classpath Embedded scenarios tend not to set up the same class loader structure as stand alone Tomcat. Often, they use a single class loader for everything. I'd check that your scenario works in a stand alone Tomcat first and once you have that working, transfer it to embedded with particular attention to class loader configuration. Mark > > Chirag > > On Wed, 22 Jul, 2020, 4:03 pm Mark Thomas, wrote: > >> On 22/07/2020 11:18, Chirag Dewan wrote: >>> Hi, >>> >>> Due to some backward compatibility concerns, I need to support both >>> Jersey-1 and Jersey-2 on the same Tomcat instance. This is an embedded >>> tomcat which runs inside a JVM application. >>> >>> Since, Jersey-1 and Jersey-2 have different JAXRS versions, I tried to >>> remove both jsr311 and javax.ws.rs-2 from my JVMs classpath. And instead >>> packaged these in the WAR/WEB-INF\lib along with jersey version specific >>> jars like jersey-core-1.x, jersey-common-2.x etc. >>> >>> Now when I start my Jersey-1 application, it couldn't find >>> javax.ws.rs.ext.MessageBodyReader. >>> >>> I read Classloader HOW-TO and although it says that the order of loading >>> JavaEE classes is bootstrap first, it never says anything about WEB-INF >> as >>> a source for these jars. >>> >>> So if there any way I can load javax.* classes from WEB-INF\lib? >> >> Tomcat version? >> >> Different Tomcat versions have taken different approaches to >> implementing this requirement. A recent(ish) implementation should be >> fine but with the exact version number we can give a better answer. >> >> Mark >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Classloading Behavior in Embedded Tomcat
Thanks for a very quick reply Mark. The Tomcat version is 8.5.46. Though I do plan to upgrade to 9.0.36 in the coming weeks. Chirag On Wed, 22 Jul, 2020, 4:03 pm Mark Thomas, wrote: > On 22/07/2020 11:18, Chirag Dewan wrote: > > Hi, > > > > Due to some backward compatibility concerns, I need to support both > > Jersey-1 and Jersey-2 on the same Tomcat instance. This is an embedded > > tomcat which runs inside a JVM application. > > > > Since, Jersey-1 and Jersey-2 have different JAXRS versions, I tried to > > remove both jsr311 and javax.ws.rs-2 from my JVMs classpath. And instead > > packaged these in the WAR/WEB-INF\lib along with jersey version specific > > jars like jersey-core-1.x, jersey-common-2.x etc. > > > > Now when I start my Jersey-1 application, it couldn't find > > javax.ws.rs.ext.MessageBodyReader. > > > > I read Classloader HOW-TO and although it says that the order of loading > > JavaEE classes is bootstrap first, it never says anything about WEB-INF > as > > a source for these jars. > > > > So if there any way I can load javax.* classes from WEB-INF\lib? > > Tomcat version? > > Different Tomcat versions have taken different approaches to > implementing this requirement. A recent(ish) implementation should be > fine but with the exact version number we can give a better answer. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Classloading Behavior in Embedded Tomcat
On 22/07/2020 11:18, Chirag Dewan wrote: > Hi, > > Due to some backward compatibility concerns, I need to support both > Jersey-1 and Jersey-2 on the same Tomcat instance. This is an embedded > tomcat which runs inside a JVM application. > > Since, Jersey-1 and Jersey-2 have different JAXRS versions, I tried to > remove both jsr311 and javax.ws.rs-2 from my JVMs classpath. And instead > packaged these in the WAR/WEB-INF\lib along with jersey version specific > jars like jersey-core-1.x, jersey-common-2.x etc. > > Now when I start my Jersey-1 application, it couldn't find > javax.ws.rs.ext.MessageBodyReader. > > I read Classloader HOW-TO and although it says that the order of loading > JavaEE classes is bootstrap first, it never says anything about WEB-INF as > a source for these jars. > > So if there any way I can load javax.* classes from WEB-INF\lib? Tomcat version? Different Tomcat versions have taken different approaches to implementing this requirement. A recent(ish) implementation should be fine but with the exact version number we can give a better answer. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Classloading Behavior in Embedded Tomcat
Hi, Due to some backward compatibility concerns, I need to support both Jersey-1 and Jersey-2 on the same Tomcat instance. This is an embedded tomcat which runs inside a JVM application. Since, Jersey-1 and Jersey-2 have different JAXRS versions, I tried to remove both jsr311 and javax.ws.rs-2 from my JVMs classpath. And instead packaged these in the WAR/WEB-INF\lib along with jersey version specific jars like jersey-core-1.x, jersey-common-2.x etc. Now when I start my Jersey-1 application, it couldn't find javax.ws.rs.ext.MessageBodyReader. I read Classloader HOW-TO and although it says that the order of loading JavaEE classes is bootstrap first, it never says anything about WEB-INF as a source for these jars. So if there any way I can load javax.* classes from WEB-INF\lib? Thanks in advance Chirag
Re: Memory leak in the PKCS11 how to fix the problem
Hi Ragavendhiran, On Sat, Jul 18, 2020 at 3:55 PM Ragavendhiran Bhiman (rabhiman) wrote: > Hello All, > > > > I am seeing the memory leaks from tomcat apache in the following SSL path > using PKCS11. Attached the flame graph of memory possible memory leaks in > this area. > > Please check the attached flame graph of the memory trace. On simply a > long run the memory keep on allocated in these back traces only causing the > memory leak, and the polling of the async profiler for more than 6hours > shows this clearly. Could you please help how to fix this problem? > > (open this svg graph in browser only) > > > > Note: If C_DestroyObject is not called because of finalizer accumulation > is also tested by inducing the gc using the jmap command still could see > the memory never gone down after the Full GC collection as well. Expecting > your advice on the same. > With AsyncProfiler '-e alloc' you can see what part of the code is responsible for making most of the memory allocations, but it doesn't tell you whether those objects leak or not. AsyncProfiler helps you to identify the top allocations and if you manage to reduce them then you will reduce the GC runs and the time they take. To debug memory leaks you need to take a heap dump, e.g. with 'jmap -dump:live,format=b,file=heap.bin ' and analyze it. I'd recommend you to use Eclipse MAT to do that. Also in your flame graph I see that Netty is responsible for 49.04% of the allocated objects and Tomcat for just 25.32%. > > Regards, > > Raghav > > Infrastructure engineer, > > Cisco ISE. > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rewrite Valve Problem
Hi Jerry, On Tue, Jul 21, 2020 at 2:39 AM Jerry Malcolm wrote: > > On 7/20/2020 5:00 PM, Mark Thomas wrote: > > On 20/07/2020 22:43, Jerry Malcolm wrote: > > > > > > > >>> Do you have a ROOT web application deployed? If not, this could be > >>> https://bz.apache.org/bugzilla/show_bug.cgi?id=64593 > >> Mark, I do not have a root context. So that very likely is the > >> problem. Not 100% sure why the thought is that there should always be a > >> root context. But I'm sure there are good reasons. Easy enough to > >> create one. I'll let you know. > > Generally, I'd expect to see a ROOT context so there is something there > > to handle requests that don't map to any other context. It is easier to > > deploy custom 404 error pages if you have a ROOT context for example. > > > > That said, it isn't necessary and we do treat stuff not working without > > a ROOT context as a bug. > > > > All you need to fix BZ 64593 is a directory called ROOT in webapps. > > Wow. 4 little letters I've been using TC for over 15 years without > a ROOT. Probably because I never routed anything through mod_jk that > didn't match a known context. I have no problem if you want to treat > not having a ROOT context as a bug, But please give an error message > As explained earlier by Mark this was a bug and it is fixed for the next release. Using a dummy ROOT folder is a workaround until the next release. > in startup and/or provide an error message if/when rewrite valve fails > because there is no ROOT context defined. Thank you for explaining > what's happening. There is not a chance I would have correlated my > symptoms in 100 years to not having a ROOT context. I really do > appreciate the help. All working now > > Jerry > > > Mark > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
