RE: Memory Leakage Problem in Tomcat 7.0.94
HI Christopher, Thanks for you valuable reply, >>>1. Allow Tomcat to clear these references, and otherwise ignore the error messages. Can you please let us know how to Allow Tomcat to clear these references? --Ankit -Original Message- From: Christopher Schultz Sent: 10 October 2019 11:08 PM To: users@tomcat.apache.org Subject: Re: Memory Leakage Problem in Tomcat 7.0.94 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ankit, On 10/10/19 10:17, ankitr.de...@spec-india.com wrote: > We are using Tomcat 7.0.94 version and we have facing memory leakage > issue when tomcat server is going to shutdown. > > Please help in this case, how to solve these kind of logs? > > Please find below sample logs from catalina.log file and code. > > > > Oct 10, 2019 6:35:36 PM > org.apache.catalina.loader.WebappClassLoaderBase > clearReferencesThreads > > SEVERE: The web application [/TLSAdmin] appears to have started a > thread named [Timer-0] but has failed to stop it. This is very likely > to create a memory leak. Your application started this thread and hasn't stopped it. (See below) > Oct 10, 2019 6:35:36 PM > org.apache.catalina.loader.WebappClassLoaderBase > clearReferencesThreads > > SEVERE: The web application [/TLSAdmin] appears to have started a > thread named [schedulerFactory_Worker-1] but has failed to stop it. > This is very likely to create a memory leak. Same here, except it's likely to be a thread pool with a number of threads with similar names. To fix the thread issues, you need to find the place in your code where the threads are started (or the threadpool is created) and make sure that you have access to that thread (or pool) during application shutdown. Storing stuff like this in the application (context) scope is one way to do it. I would recommend another ServletContextListener that locates those threads (pools) and stops them. Remember that Thread.stop() doesn't really work. Instead, you have to let the thread know that it's time to stop itself. Threads called "Timer-X" are usually simple threads created by java.util.TimerTask and friends, and you should be able to store a reference to the task and stop it on app shutdown. > [snip] > Oct 10, 2019 6:35:36 PM > org.apache.catalina.loader.WebappClassLoaderBase > checkThreadLocalMapForLeaks > > SEVERE: The web application [/TLSAdmin] created a ThreadLocal with key > of type [java.lang.ThreadLocal] (value > [java.lang.ThreadLocal@794fa987]) and a value of type > [flex.messaging.config.SystemSettings] (value > [flex.messaging.config.SystemSettings@7dca495e]) but failed to remove > it when the web application was stopped. Threads are going to be > renewed over time to try and avoid a probable memory leak. Something in "flex" has put an object in ThreadLocal storage and never removed it. This is harder to fix than the threading stuff because you each thread needs to purge the ThreadLocal objects in order to "clean" the system. You have two options, really: 1. Allow Tomcat to clear these references, and otherwise ignore the error messages. 2. Change your application so that at the end of each request you remove these ThreadLocal values from the request-processing thread. Hope that helps, - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2fbHsACgkQHPApP6U8 pFhmTg/7BPeaBmZ073LRDTc6Am3HkEtpL8ZKzuN1utqc0EsYlzJAUc1G4nBHenuE HM6FDDKOXcKa7nQnN+A63S9zMu0b/K9HZT+bA6TFpIeypx//c8lcxAxqwFJLXaQS IE5YU0cmBc3njMpHSUqE16/dRl1KoyJWWwqUSXDVsJLA/RTaheOq14T0BjaTDSaN dgX+80mbovwkwKzhbZETGP2OY+wJ0GGje3FtXqdFqPp6evlaekHRNXC0N+4VHSNe XNkfjkfdJldAulpbxPj5eulg5ONyQVRHG3nRSUHeH7Q0v4uhjy7tYcd7PwVLr3s1 RzFeK35gqRYmVXGqf+kEMLkBQbW04LEAukzG5SZPpGHLkyL10dBv3Z7eulILiwP0 +pm79SluHi1nHGd6CSzrMc+Sv9FF8hxwxkph2i/Ec3w/j6/hNvD+whJgEQh44mbF MiGTs58OJEyICjUfFhcAVEvrkcDSzq/kmgL57dCm2P/LGzieH611fB0ipSMzcmpD Pt21ATqWEKWJrecMc2qAo44jPxbW0FEcbmFNSKfMUOYWg3KDiOrH32Byb9OPFrgq RxKmNRx0KBWZUnj+yZKp71l3OOmrFswfDnGIigm2k9aVuY0s3FcJfAUM20/wAG+W rDropeU+g+2wmo7Ak0ZoZR8zcoh1j7PrWFld36XNVMxoT38aFjY= =ZMog -END PGP SIGNATURE- - 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
tomcat with SiteMinder
Has anyone used tomcat with SiteMinder without having a webserver in front of it? If so, where can I find the how to? thank you, *Peggy *
RE: Performance test with Tomcat 9 shows increased cpu/disk usage because of repeated opening/closing of jars in WEB-INF/lib
Tony, > -Original Message- > From: Rhuberg,Anthony > Sent: Thursday, October 10, 2019 5:22 PM > To: Tomcat Users List > Subject: RE: Performance test with Tomcat 9 shows increased cpu/disk usage > because of repeated opening/closing of jars in WEB-INF/lib > > We are still investigating what specific classloader reads that would trigger > the repeated reload of the web-inf/lib/*.jars. > > One example we found is the use of > javax.xml.transform.TransformerFactory.newInstance(). One of its features > is to determine the implementation by searching for the configuration > specified by META-INF/services/javax.xml.transform.TransformerFactory in > jars available to the runtime. > Yep. I was wondering about that. I have no idea why this behavior would be different in Tomcat 9, though. Did you change Java versions also? Is the classpath longer? I also have no idea about the jar modification date changes that you're seeing. I do have first-hand experience with the performance of TransformerFactory.newInstance(). In general, anything that uses the service locator under the covers, such as TransformerFactory, DocumentBuilderFactory, etc, should be reused if possible. Those XML factories are thread safe, though the things created by the factories are typically not thread safe. You should create it once, configure it once, and use it as many times as necessary. For example, you would create one TransformerFactory, then call newTransformer() as many times as necessary. John
RE: Performance test with Tomcat 9 shows increased cpu/disk usage because of repeated opening/closing of jars in WEB-INF/lib
We are still investigating what specific classloader reads that would trigger the repeated reload of the web-inf/lib/*.jars. One example we found is the use of javax.xml.transform.TransformerFactory.newInstance(). One of its features is to determine the implementation by searching for the configuration specified by META-INF/services/javax.xml.transform.TransformerFactory in jars available to the runtime. It seems users of Tomcat 9 would need to understand the management of the jar resource handles when using the TransformerFactory class - assuming it is triggering the reload of all the related application jars - which if happening enough can cause the high cpu/disk usage as we observed in our performance tests. Thanks -Original Message- From: Mark Thomas Sent: Thursday, October 10, 2019 3:54 AM To: users@tomcat.apache.org Subject: Re: Performance test with Tomcat 9 shows increased cpu/disk usage because of repeated opening/closing of jars in WEB-INF/lib On 09/10/2019 22:58, Rhuberg,Anthony wrote: > StandardRoot.gc() unconditionally closes the web application jars in Tomcat > 9... every 10s by default or configurable by changing > backgroundProcessorDelay. > > So then the problem is Our web application is calling > class.getResourceAsStream() to read some static files... and this is causing > the jars to be read again? It sounds like it. > This was not a problem with Tomcat 7 because the jars were not closed if they > were read within the jarOpenInterval setting? Or that the frequency that the JARs were closed was low enough that the performance impact was not noticed. Mark > > Thanks, > Tony > > -Original Message- > From: Mark Thomas > Sent: Wednesday, October 09, 2019 5:32 PM > To: users@tomcat.apache.org > Subject: Re: Performance test with Tomcat 9 shows increased cpu/disk > usage because of repeated opening/closing of jars in WEB-INF/lib > > On 09/10/2019 21:03, Rhuberg,Anthony wrote: >> This seems to alleviate the issue... in context.xml (sc-test#sc.xml) >> > swallowOutput="true" backgroundProcessorDelay="90"> >> >> Not sure if this is the context reload trigger... i.e. the >> webappLoader.backgroundProcess method is triggered every 90 seconds... > > It isn't. It is StandardRoot.gc() that is unloading the cached JAR entries. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > CONFIDENTIALITY NOTICE This message and any included attachments are from > Cerner Corporation and are intended only for the addressee. The information > contained in this message is confidential and may constitute inside or > non-public information under international, federal, or state securities > laws. Unauthorized forwarding, printing, copying, distribution, or use of > such information is strictly prohibited and may be unlawful. If you are not > the addressee, please promptly delete this message and notify the sender of > the delivery error by e-mail or you may call Cerner's corporate offices in > Kansas City, Missouri, U.S.A at (+1) (816)221-1024. > > - > 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: Setting samesite attribute on JSESSIONID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dave, On 10/10/19 14:08, David Cleary wrote: > Have a customer asking about this. I see Tomcat supports it here. > https://tomcat.apache.org/tomcat-9.0-doc/config/cookie-processor.html > > > We currently use defaults, so I'm looking for an XML fragment and > the file it goes in to add the samesite attribute to the > JSESSIONID. I'm assuming they want it globally for all webapps. What have you tried already? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2fdcEACgkQHPApP6U8 pFjgrQ/6A6MaxzldDfEmTLEejDJ4uv8q2uqwSa4F4s//bTa2Lp9vTcJd5Krkv/8W GtELeEjSj16Xuk9Je9ue1/AKVxYFvxAPW1Z8vsPj2GRIytj9vcMp8tkavPq6nonj F365HNTBa75oDDwxYZboirq2846YMBqLPPWRiVRS5JBJISzlhHvWp5+Pa8fyVZaA mKnR1VlZgflzYUvSwwtsnYDE2r3iNYPGYwHXCBnGJFcpM9DLPK4Yho7LAM87jIjn ljYytsZRwLZQIw48DfyB4GAYWEglr9vGGrEqDTOX7rDbln18MnxI8rzn7oOr4CvX EOsLPy3Cxb3M8F+jSdvzCcB4FTwerfaEvu88lnQLrBtauhWs2D06YCukQT/ITCWV WZSN4g3eBThP/Uz9ju2QKkKsDPNLSgk+dXtVQGvpoIi27AEm5GkVbTGJbGMr6OMj 4q8Jw+DlYO5eIkk8tlQLDQXno5OSCXqSuA++VWs9FzwpFaCY4r4hlPopi4NYGFOt bgXmfMHGdh+VFXNnJyzGuPUOWhuY3kj4rIs5KlwoFjPdKOBj5R+dT21f0OnFVoM+ QvdwkLNF1sIWBu7yBsyqJ+gUgr8Z9tKSHV3Ye7JqB7dJ1gpl3pPe+TRYHuD1aDWR X+Yie7xUbdOgQuer4a+Kpcytfy+LxPVUl1oKTX1ReKyyn4eXFLE= =lIGD -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Setting samesite attribute on JSESSIONID
Have a customer asking about this. I see Tomcat supports it here. https://tomcat.apache.org/tomcat-9.0-doc/config/cookie-processor.html We currently use defaults, so I'm looking for an XML fragment and the file it goes in to add the samesite attribute to the JSESSIONID. I'm assuming they want it globally for all webapps. Thanks Dave
Re: Understanding NIO connector
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Filippo, On 10/10/19 11:47, Filippo Machi wrote: > Hello everybody, I am trying to understand in which way tomcat is > handling incoming connections. We have a spring boot application in > production that is using tomcat embedded (version 8.x) and since we > are experiencing some issues with Too Many Files open, we would > like to understand properly in which way the application is > handling incoming connections from the clients. Is there any > resource that explains what is in charge of the operating system > and what is in charge of Tomcat. I would like to understand all > the steps a request goes through in order to be handled and alsohow > does the NIO connector works considering mainly those three > parameters: - maxConnections - acceptCount - maxThreads There's a lot of information to give you, and maybe all at once isn't the right approach. Let's start with those three settings you have above . > - maxConnections This one is easy: it's the maximum number of TCP/IP connections that the connector will open. By default for the NIO connector, it's 1. > - acceptCount This is a hint to the operating system as to how many incoming connections should be allowed to queue-up in the TCP/IP "backlog" before refusing requests. It's easier to explain what happens to clients than to use the "official" terminology if you aren't familiar with it: If you have maxConnections="10" and acceptCount="0" then 10 clients will connect and (assuming none of the first 10 requests complete), the 11th client will get a "connection refused" error. If maxConnections="10" and acceptCount="10" then 10 clients can connect and work begins immediately on their requests. The next 10 clients (assuming none of the first 10 have completed) sit in the TCP/IP backlog queue but don't actually "connect" yet. The 21st client get a "connection refused" error. Once the first client's request completes, one of the "backlogged"/"queued" connections will *actually* connect, and then processing begins on that client's request. Please note that acceptCount is just a hint to the OS. You can set it to "0" and maybe you'll still get a non-zero backlog queue. Or maybe you'll set it to "1" and only 100 connections will actually be queued. You can't force the OS to do something it doesn't want to do :) > - maxThreads This is easy, too: this is the maximum number of request-processing threads that will be created in order to process requests. This number is *per connector* and so if you have more than one connector with different numbers, you'll get the sum of those two numbers as your total number of request-processing threads in your server. Connectors that are configured separately *do not* share these threads. Connectors configured with an "executor" will share the executor if the names are the same, and you'll only get "maxThreads" threads (and not, for example, maxThreads * 2 for two connectors sharing a single executor). If you are getting TooManyFilesOpen errors, hen you are running out of "file handles". You didn't say which OS you were on, so I'll assume *NIX since that's what I actually know :) Handles to actual on-disk files are "file descriptors". But network connections are also file descriptors, and they can really add up. Each process has a limit on the number of file descriptors that it can create before the OS refuses to create new ones. This is a protection the OS places on processes so they don't use up all the resources in the system. Sometimes, this limit is just too low and needs to be raised for e.g. Tomcat to be able to do its job. Sometimes it means that you have things misconfigured. What does your configuration look like and what are the circumstances under which you are getting these "too many open files" errors? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2fcZ0ACgkQHPApP6U8 pFhhcQ/5Adc2wyu0GTQrX+H6BMlB6N7VSchz2rHV5cM+jMatCFKcvkYAqL6m0Rbn jdlzakE26nQ+nEBThAJB9b6cs1DNWApE4TtZTuItdVNhik0ClQkBhYFrZ4HpsXsx ZAsgPgVeYNb9kXXkIRstjnia+vq6i3/VarYdJXlbnEjXzu+eyC8+HQh8DlyIO6hr sTmgPb1Iw7+Z1WM1oNA1E5dmxF2R/Q6RgWsFMGm9BniDG/0FFiHHOr+71LQqe/DH e72Gh5Wcwy8i8rOkSA/OkGJ8wZvkHHEd+VqCI3hmRt7mGyOKoC8RQBpp5RbFkfFz KxdzJrMTQ64gMXD/bPNT3TYBft1j84DYHwyktzBEPBhZgjuTdd1R4eOFmGLuCcqm 1NE0aqvCCRnVcPhEfewz2MENe4c9QF0N8YTqgvmTV6P1v1fTE1C4t03fA/5dsGvx ksVKiJjouakPMRQD/lsdY0kuF7rlDwPwDs0cbx94e/FeiiTht2Mb8YiOToLEk/4C 95dTdEUhNX+i/gK6BduhSCfggNb5eUGj+VExH+OQD0Y9f9exaqzLM7sTYaCEh8uI Co/MkpiqKdIddsZnsSYKn5tgfYYJSiwT8GZAuv/x5Dj7ZCiTZFy85/cuA0GVWpqz pMPMU6v4jnIo5RiIBTonJ9uKOElYA5MKibgwa2aZ+03F0y7MuV4= =F7QI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Memory Leakage Problem in Tomcat 7.0.94
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ankit, On 10/10/19 10:17, ankitr.de...@spec-india.com wrote: > We are using Tomcat 7.0.94 version and we have facing memory > leakage issue when tomcat server is going to shutdown. > > Please help in this case, how to solve these kind of logs? > > Please find below sample logs from catalina.log file and code. > > > > Oct 10, 2019 6:35:36 PM > org.apache.catalina.loader.WebappClassLoaderBase > clearReferencesThreads > > SEVERE: The web application [/TLSAdmin] appears to have started a > thread named [Timer-0] but has failed to stop it. This is very > likely to create a memory leak. Your application started this thread and hasn't stopped it. (See below) > Oct 10, 2019 6:35:36 PM > org.apache.catalina.loader.WebappClassLoaderBase > clearReferencesThreads > > SEVERE: The web application [/TLSAdmin] appears to have started a > thread named [schedulerFactory_Worker-1] but has failed to stop it. > This is very likely to create a memory leak. Same here, except it's likely to be a thread pool with a number of threads with similar names. To fix the thread issues, you need to find the place in your code where the threads are started (or the threadpool is created) and make sure that you have access to that thread (or pool) during application shutdown. Storing stuff like this in the application (context) scope is one way to do it. I would recommend another ServletContextListener that locates those threads (pools) and stops them. Remember that Thread.stop() doesn't really work. Instead, you have to let the thread know that it's time to stop itself. Threads called "Timer-X" are usually simple threads created by java.util.TimerTask and friends, and you should be able to store a reference to the task and stop it on app shutdown. > [snip] > Oct 10, 2019 6:35:36 PM > org.apache.catalina.loader.WebappClassLoaderBase > checkThreadLocalMapForLeaks > > SEVERE: The web application [/TLSAdmin] created a ThreadLocal with > key of type [java.lang.ThreadLocal] (value > [java.lang.ThreadLocal@794fa987]) and a value of type > [flex.messaging.config.SystemSettings] (value > [flex.messaging.config.SystemSettings@7dca495e]) but failed to > remove it when the web application was stopped. Threads are going > to be renewed over time to try and avoid a probable memory leak. Something in "flex" has put an object in ThreadLocal storage and never removed it. This is harder to fix than the threading stuff because you each thread needs to purge the ThreadLocal objects in order to "clean" the system. You have two options, really: 1. Allow Tomcat to clear these references, and otherwise ignore the error messages. 2. Change your application so that at the end of each request you remove these ThreadLocal values from the request-processing thread. Hope that helps, - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2fbHsACgkQHPApP6U8 pFhmTg/7BPeaBmZ073LRDTc6Am3HkEtpL8ZKzuN1utqc0EsYlzJAUc1G4nBHenuE HM6FDDKOXcKa7nQnN+A63S9zMu0b/K9HZT+bA6TFpIeypx//c8lcxAxqwFJLXaQS IE5YU0cmBc3njMpHSUqE16/dRl1KoyJWWwqUSXDVsJLA/RTaheOq14T0BjaTDSaN dgX+80mbovwkwKzhbZETGP2OY+wJ0GGje3FtXqdFqPp6evlaekHRNXC0N+4VHSNe XNkfjkfdJldAulpbxPj5eulg5ONyQVRHG3nRSUHeH7Q0v4uhjy7tYcd7PwVLr3s1 RzFeK35gqRYmVXGqf+kEMLkBQbW04LEAukzG5SZPpGHLkyL10dBv3Z7eulILiwP0 +pm79SluHi1nHGd6CSzrMc+Sv9FF8hxwxkph2i/Ec3w/j6/hNvD+whJgEQh44mbF MiGTs58OJEyICjUfFhcAVEvrkcDSzq/kmgL57dCm2P/LGzieH611fB0ipSMzcmpD Pt21ATqWEKWJrecMc2qAo44jPxbW0FEcbmFNSKfMUOYWg3KDiOrH32Byb9OPFrgq RxKmNRx0KBWZUnj+yZKp71l3OOmrFswfDnGIigm2k9aVuY0s3FcJfAUM20/wAG+W rDropeU+g+2wmo7Ak0ZoZR8zcoh1j7PrWFld36XNVMxoT38aFjY= =ZMog -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: NPE in DBCP when attempting to connect to a database that doesn't exist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Adam,
On 10/9/19 20:59, Adam Rauch wrote:
> When attempting to connect to a DataSource that specifies a
> database that doesn't exist, Tomcat 8.5.46 throws an informative
> SQLException; for example: java.sql.SQLException: Cannot create
> PoolableConnectionFactory (FATAL: database "labkey19.3" does not
> exist)
>
> In the same situation, Tomcat 7.0.96 throws a NullPointerException
> with no useful information.
>
> I expect an exception, but the 8.5.46/DBCP2 behavior is obviously
> preferable, since it gives administrators a better understanding
> of what's gone wrong. Seems like a DBCP 1.x bug (not a Tomcat bug)
> and I wouldn't consider it a high priority to fix (our product
> recovers just fine in either case and we recommend Tomcat 9.0.x
> these days), but the discrepancy seemed worth mentioning here.
>
> Full stack traces below. Our code is simply:
>
> try (Connection conn = dataSource.getConnection()) { ... }
>
> Thanks, Adam
Sounds like a bona-fide bug. Can you please file this in Bugzilla?
- -chris
>
> Tomcat 7.0.96
>
> java.lang.NullPointerException at
> org.apache.tomcat.dbcp.dbcp.PoolableConnectionFactory.destroyObject(Po
olableConnectionFactory.java:643)
>
> at
> org.apache.tomcat.dbcp.dbcp.BasicDataSource.validateConnectionFactory(
BasicDataSource.java:1738)
>
> at
> org.apache.tomcat.dbcp.dbcp.BasicDataSource.createPoolableConnectionFa
ctory(BasicDataSource.java:1721)
>
> at
> org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicData
Source.java:1486)
>
> at
> org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSou
rce.java:1103)
>
> at org.labkey.api.data.DbScope.(DbScope.java:337) at
> org.labkey.api.data.DbScope.addScope(DbScope.java:1275) at
> org.labkey.api.data.DbScope.initializeScopes(DbScope.java:1243) at
> org.labkey.api.module.ModuleLoader.initializeDataSources(ModuleLoader.
java:1004)
>
> at
> org.labkey.api.module.ModuleLoader.doInit(ModuleLoader.java:352) at
> org.labkey.api.module.ModuleLoader.init(ModuleLoader.java:249) at
> org.apache.catalina.core.ApplicationFilterConfig.initFilter(Applicatio
nFilterConfig.java:285)
>
> at
> org.apache.catalina.core.ApplicationFilterConfig.getFilter(Application
FilterConfig.java:266)
>
> at
> org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFil
terConfig.java:108)
>
> at
> org.apache.catalina.core.StandardContext.filterStart(StandardContext.j
ava:5037)
>
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext
.java:5739)
>
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
>
>
at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.
java:1018)
>
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:994
)
>
>
at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:662)
>
>
at
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.jav
a:712)
>
> at
> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig
.java:2002)
>
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executor
s.java:515)
>
> at
> java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.jav
a:264)
>
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
Executor.java:1128)
>
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
lExecutor.java:628)
>
> at java.base/java.lang.Thread.run(Thread.java:830)
>
> Tomcat 8.5.46
>
> java.sql.SQLException: Cannot create PoolableConnectionFactory
> (FATAL: database "labkey19.3" does not exist) at
> org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createPoolableConnectionF
actory(BasicDataSource.java:669)
>
> at
> org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createDataSource(BasicDat
aSource.java:544)
>
> at
> org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection(BasicDataSo
urce.java:753)
>
> at org.labkey.api.data.DbScope.(DbScope.java:337) at
> org.labkey.api.data.DbScope.addScope(DbScope.java:1275) at
> org.labkey.api.data.DbScope.initializeScopes(DbScope.java:1243) at
> org.labkey.api.module.ModuleLoader.initializeDataSources(ModuleLoader.
java:1004)
>
> at
> org.labkey.api.module.ModuleLoader.doInit(ModuleLoader.java:352) at
> org.labkey.api.module.ModuleLoader.init(ModuleLoader.java:249) at
> org.apache.catalina.core.ApplicationFilterConfig.initFilter(Applicatio
nFilterConfig.java:283)
>
> at
> org.apache.catalina.core.ApplicationFilterConfig.getFilter(Application
FilterConfig.java:264)
>
> at
> org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFil
terConfig.java:108)
>
> at
> org.apache.catalina.core.StandardContext.filterStart(StandardContext.j
ava:4546)
>
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext
.java:5191)
>
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>
>
at
>
Understanding NIO connector
Hello everybody, I am trying to understand in which way tomcat is handling incoming connections. We have a spring boot application in production that is using tomcat embedded (version 8.x) and since we are experiencing some issues with Too Many Files open, we would like to understand properly in which way the application is handling incoming connections from the clients. Is there any resource that explains what is in charge of the operating system and what is in charge of Tomcat. I would like to understand all the steps a request goes through in order to be handled and alsohow does the NIO connector works considering mainly those three parameters: - maxConnections - acceptCount - maxThreads Thanks a lot Filippo
Memory Leakage Problem in Tomcat 7.0.94
Hello, We are using Tomcat 7.0.94 version and we have facing memory leakage issue when tomcat server is going to shutdown. Please help in this case, how to solve these kind of logs? Please find below sample logs from catalina.log file and code. Oct 10, 2019 6:35:36 PM org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads SEVERE: The web application [/TLSAdmin] appears to have started a thread named [Timer-0] but has failed to stop it. This is very likely to create a memory leak. Oct 10, 2019 6:35:36 PM org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads SEVERE: The web application [/TLSAdmin] appears to have started a thread named [schedulerFactory_Worker-1] but has failed to stop it. This is very likely to create a memory leak. Oct 10, 2019 6:35:36 PM org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads SEVERE: The web application [/TLSAdmin] appears to have started a thread named [schedulerFactory_Worker-2] but has failed to stop it. This is very likely to create a memory leak. Oct 10, 2019 6:35:36 PM org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads SEVERE: The web application [/TLSAdmin] appears to have started a thread named [schedulerFactory_Worker-3] but has failed to stop it. This is very likely to create a memory leak. Oct 10, 2019 6:35:36 PM org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads SEVERE: The web application [/TLSAdmin] appears to have started a thread named [schedulerFactory_Worker-4] but has failed to stop it. This is very likely to create a memory leak. Oct 10, 2019 6:35:36 PM org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads SEVERE: The web application [/TLSAdmin] appears to have started a thread named [schedulerFactory_Worker-5] but has failed to stop it. This is very likely to create a memory leak. Oct 10, 2019 6:35:36 PM org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads SEVERE: The web application [/TLSAdmin] appears to have started a thread named [schedulerFactory_Worker-6] but has failed to stop it. This is very likely to create a memory leak. Oct 10, 2019 6:35:36 PM org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads SEVERE: The web application [/TLSAdmin] appears to have started a thread named [schedulerFactory_Worker-7] but has failed to stop it. This is very likely to create a memory leak. Oct 10, 2019 6:35:36 PM org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads SEVERE: The web application [/TLSAdmin] appears to have started a thread named [schedulerFactory_Worker-8] but has failed to stop it. This is very likely to create a memory leak. Oct 10, 2019 6:35:36 PM org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads SEVERE: The web application [/TLSAdmin] appears to have started a thread named [schedulerFactory_Worker-9] but has failed to stop it. This is very likely to create a memory leak. Oct 10, 2019 6:35:36 PM org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads SEVERE: The web application [/TLSAdmin] appears to have started a thread named [schedulerFactory_Worker-10] but has failed to stop it. This is very likely to create a memory leak. Oct 10, 2019 6:35:36 PM org.apache.catalina.loader.WebappClassLoaderBase checkThreadLocalMapForLeaks SEVERE: The web application [/TLSAdmin] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@794fa987]) and a value of type [flex.messaging.config.SystemSettings] (value [flex.messaging.config.SystemSettings@7dca495e]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. Oct 10, 2019 6:35:36 PM org.apache.catalina.loader.WebappClassLoaderBase checkThreadLocalMapForLeaks SEVERE: The web application [/TLSAdmin] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@794fa987]) and a value of type [flex.messaging.config.SystemSettings] (value [flex.messaging.config.SystemSettings@7dca495e]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. Oct 10, 2019 6:35:36 PM org.apache.catalina.loader.WebappClassLoaderBase checkThreadLocalMapForLeaks SEVERE: The web application [/TLSAdmin] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@794fa987]) and a value of type [flex.messaging.config.SystemSettings] (value [flex.messaging.config.SystemSettings@7dca495e]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. Oct 10, 2019 6:35:36 PM org.apache.coyote.AbstractProtocol stop We have implements below code for "ServletContextListener" public class LogbackContextFinalizer implements
Re: Any tutorials or hints about JSP using javax.script engines instead of Java?
Hi Chris, > On 10/9/19 07:08, Rony G. Flatscher (Apache) wrote: > > On 08.10.2019 21:16, André Warnier (tomcat) wrote: > >> On 08.10.2019 17:11, Rony G. Flatscher (Apache) wrote: > >>> Does anyone know of any tutorials that would demonstrate how to > >>> use any javax.script language in JSPs instead of Java (e.g. > >>> using Jython or JavaScript instead)? ... cut ... > My own (particularly uninformed) opinion is that most scripting > languages that have wanted to get into JVMs/app servers have simply > built their own technologies to handle everything, so it doesn't run > through JSP itself. > > For example, Lucee[1] is a CFML implementation in Java, but it doesn't > (always) use JSP. They have a separate "interpreter" for it instead of > building huge tag libraries to fit it into JSP. (I say "interpreted" > because I don't know if they actually interpret the files each time on > demand, or if there is a compilation step at some point. It doesn't > really matter either way.) > > I haven't looked at it in depth, but I believe this is also what > Apache JGroovy[2] does. > > -chris > > [1] https://lucee.org/ > [2] https://groovy-lang.org/ Maybe if some standard "script" taglib library for javax.script languages existed like the proof-of-concept one in [1] then that could be exploited/(re)used rather than coming up with non-standard implementations of their own. ---rony [1] with an example that instrumentaes PHP and Rexx. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Any tutorials or hints about JSP using javax.script engines instead of Java?
Hi Konstantin, On 09.10.2019 15:31, Konstantin Kolinko wrote: > вт, 8 окт. 2019 г. в 18:11, Rony G. Flatscher (Apache) : >> Does anyone know of any tutorials that would demonstrate how to use any >> javax.script language in >> JSPs instead of Java (e.g. using Jython or JavaScript instead)? >> >> If not, any advice/hint how to realize/create such a functionality (for then >> creating such a >> tutorial instead) would be highly appreciated! > 1. There is no such feature in Apache Tomcat. > > Tomcat implements JSP specification and the specification [1] only > supports language="java" in a JSP declaration. > > [1] > https://cwiki.apache.org/confluence/display/TOMCAT/Specifications#Specifications-JavaServerPagesandExpressionLanguageSpecifications > > Support for other language needs some specification document of such a > feature, and I do not know about any such document. Hmm, what steps would be necessary and where? One idea would be to extend the support for any of the javax.script languages. ... cut ... ---rony - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance test with Tomcat 9 shows increased cpu/disk usage because of repeated opening/closing of jars in WEB-INF/lib
On 09/10/2019 22:58, Rhuberg,Anthony wrote: > StandardRoot.gc() unconditionally closes the web application jars in Tomcat > 9... every 10s by default or configurable by changing > backgroundProcessorDelay. > > So then the problem is Our web application is calling > class.getResourceAsStream() to read some static files... and this is causing > the jars to be read again? It sounds like it. > This was not a problem with Tomcat 7 because the jars were not closed if they > were read within the jarOpenInterval setting? Or that the frequency that the JARs were closed was low enough that the performance impact was not noticed. Mark > > Thanks, > Tony > > -Original Message- > From: Mark Thomas > Sent: Wednesday, October 09, 2019 5:32 PM > To: users@tomcat.apache.org > Subject: Re: Performance test with Tomcat 9 shows increased cpu/disk usage > because of repeated opening/closing of jars in WEB-INF/lib > > On 09/10/2019 21:03, Rhuberg,Anthony wrote: >> This seems to alleviate the issue... in context.xml (sc-test#sc.xml) >> > swallowOutput="true" backgroundProcessorDelay="90"> >> >> Not sure if this is the context reload trigger... i.e. the >> webappLoader.backgroundProcess method is triggered every 90 seconds... > > It isn't. It is StandardRoot.gc() that is unloading the cached JAR entries. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > CONFIDENTIALITY NOTICE This message and any included attachments are from > Cerner Corporation and are intended only for the addressee. The information > contained in this message is confidential and may constitute inside or > non-public information under international, federal, or state securities > laws. Unauthorized forwarding, printing, copying, distribution, or use of > such information is strictly prohibited and may be unlawful. If you are not > the addressee, please promptly delete this message and notify the sender of > the delivery error by e-mail or you may call Cerner's corporate offices in > Kansas City, Missouri, U.S.A at (+1) (816)221-1024. > > - > 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
