Re: Per context heap usage
On Wed, 2022-05-18 at 17:36 -0400, Christopher Schultz wrote: > > > > > Is it possible to find out the per deployed context heap usage in > > > > > tomcat? > > > > > > > > With a profiler you can look at the retained size of the web > > > > application class loader instance associated with a web application. > > > > What reference path would lead from a java.lang.String object to the web > application ClassLoader? It's allocation-path? That would be tied to the > Thread which allocated it, not to the TCCL the Thread happened to have > at the time. If you look at a memory dump you can follow the references both up and down Going up means asking "who owns this object" or "what class keeps this object alive". Going down means asking "What fields does this class hold" With modern memory profilers you can aks for the retained set of objects, the profiler will then start from the root objects and go down and calculate how much memory is hanging under each object. Since the jvm heap is a graph with circles this is a bit tricky, but that is for the profile writers to figure out. So if we look at a hypothetical example: Tomcat holds references to one or more classloaders, one per webapp. Each such classloader holds on to a set of servlets. Each servlet holds on to its own resources. So when you look at the retained sets you se something like: Tomcat holds 100% of the memory - Classloader for webapp 1 holds 80% of the memory - Servlet A holds 79% of the memory - Servlet B holds 1% of the memory - Classloader for webapp 2 holds 15% of the memory - classloader for webapp 3 holds 5% of the memory This is of course a simplified example and common things may make the statistics hard to read. Personally I have used both visualvm and eclipse mat to look at memory profiles. Both of them support retained set calculations, but with the last releases of java I have only managed to get visualvm working well. If you get eclipse mat working with this it tends to be a bit more helpful. Hope that makes sense! /robo - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Re: Question about DirResourceSet?
Hi! On Tue, 2019-10-15 at 14:37 +0100, Mark Thomas wrote: > Generally, no. You've done it in what I'd consider to be the "safer" way > by exposing all the JARs visible to the client to the application's > class loader rather than the other way around. Ok, good to hear, we will try this and see how things work out. I am happy to hear that you reflected about security and as far as I know we do not have any upload into the web app (and I ought to know if we do :-). Security was one of the main reason for my questions. > another option would be to use a ServletContextListener to copy the > files... Sure, but just pointing out another directory is a lot easier. Thanks a lot. /robo - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Question about DirResourceSet?
Hi! Some background: We are currently running tomcat (9.0.26) and we serve data to both html/webapp and to our java application. The java application uses a lot of the same jar files that our servlets use. We have had tomcat setup with two directories: 1) webapps//WEB-INF/lib (as usual for servlet classes) 2) webapps//clientdir/ (jar files for the java application). This means that we have a lot of duplication of jar files in these two directories. We would like to have the duplicate files in only one place, sure disk space is cheap, but data transfer takes time. We thought that having the jars in the clientdir would be nice. We have read the documentation for tomcat and found the resource handling and it looks like we could possibly use something like: We tested this lightly and things seems to work. Questions: Is there any problem with this? If so, do you know of any better way to accomplish this? Thanks /robo - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
External entities in web.xml
Hi! I just started an upgrade of our tomcat, 7.0.47, to 7.0.52 and got into a problem. Tomcat did not want to start our webapp. Looking in the log I see: Mar 26, 2014 2:10:42 PM org.apache.catalina.startup.ContextConfig parseWebXml SEVERE: Parse error in application web.xml file at jndi:/localhost/bios/WEB-INF/web.xml java.io.FileNotFoundException: Could not resolve XML resource [null] with public ID [null], system ID [dpservices.xml] and base URI [jndi:/localhost/bios/WEB-INF/web.xml] to a known, local entity. Not very helpful! Looking in our web.xml I find that it starts with: ?xml version=1.0? !DOCTYPE web-app [ !ENTITY service SYSTEM dpservices.xml] ... Checking the directory and the dpservices.xml file is there. After a bit of git cloning, git grep:ing and similar I find that: 7.0.51:Change default value of |xmlBlockExternal| attribute of Context. It is |true| now There is no bug referenced so I am not sure why this change was made. Is there some security problem with external entities that I should know of? Is there a bug where I can read more? (I can not been able to find anything specific to this from google). Setting xmlBlockExternal=false in the context makes things start up as they should again and I can continue with testing the new version. It would be nicer if the parse error also said something like ...external entities are not allowed, check the xmlBlockExternal context property... /robo
Re: Tomcat slow during startup = 7.0.28
On 11/21/2013 03:17 PM, Mark Thomas wrote: You appear to be complaining about specification mandated behaviour. The scan is required as soon as there is an SCI that declares an interest in a class. As far as I know we do not use any such thing. We do use two ServletContextListener and from the stack trace they could be the problem. Both of them are in web.xml, Is there some log I can turn on to figure out why this scan is happening? One might equally ask if you have any plans to fix your poorly configured application. Well, perhaps the application is poorly configured, but there is still a major change in startup time from one release to the next in the same major version and I would consider that a regression. Use absolute-ordering / since that will exclude every JAR from the annotation scan for matches to the SCIs. That seems to bring me down to less than one second again. I will test that some more and see what breaks. Thanks! /robo - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat slow during startup = 7.0.28
Hi! I have tried to upgrade our system to more modern tomcat (from 7.0.28) to 7.0.47 and we also get the slow startup due to annotations processing. In my case it makes tomcat startup go from 1 second to ~8 seconds and for development that is annoying, even if it is not critical for production servers. This system has ROOT+one webapp. The webapp is not very large, but there are 350 jars in WEB-INF/lib. Setting metadata-complete=true has very little affect (it shaves of about 0.5 seconds) As I understand it this has been a known problem since january, anyone know if there is an open bug on it or a plan to fix it? Is there any suggestions on what to do more to get a faster startup? Thread dumps all look like this: localhost-startStop-1 daemon prio=10 tid=0x7f713c003800 nid=0x1d2e runnable [0x7f7147a9f000] java.lang.Thread.State: RUNNABLE at java.lang.Object.init(Object.java:37) at java.io.InputStream.init(InputStream.java:45) at java.util.zip.ZipFile$ZipFileInputStream.init(ZipFile.java:657) at java.util.zip.ZipFile.getInputStream(ZipFile.java:354) - locked 0x0007ad535b70 (a sun.net.www.protocol.jar.URLJarFile) at java.util.jar.JarFile.getInputStream(JarFile.java:409) - locked 0x0007ad535b70 (a sun.net.www.protocol.jar.URLJarFile) at org.apache.tomcat.util.scan.FileUrlJar.getEntryInputStream(FileUrlJar.java:97) at org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:2009) at org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1976) at org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1961) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1319) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:878) - locked 0x0007b4d77a70 (a org.apache.catalina.startup.ContextConfig) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:376) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5322) - locked 0x0007b4d77570 (a org.apache.catalina.core.StandardContext) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) - locked 0x0007b4d77570 (a org.apache.catalina.core.StandardContext) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:663) at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1642) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) Thanks! /robo
