Tomcat8 gives me WSOD due to LinkageError
Hello list, I'm not sure if this the right place to ask, but here it goes... I have a existing WebApp that I'm planning to upgrade to Tomcat8 (version 8.0.20 as of today). It is running stable in Tomcat7 already for ages. Tomcat8 does not embed the JasperListener so I added it manually to my pom.xml otherwise I was getting NoClassDefFoundError. dependency groupIdorg.apache.tomcat/groupId artifactIdtomcat-jasper/artifactId version8.0.20/version /dependency The application bootstraps properly but when I launch a request to it, I'm getting the following exception; Caused by: java.lang.LinkageError: loader constraint violation: when resolving method org.apache.jasper.runtime.InstanceManagerFactory.getInstanceManager(Ljavax/servlet/ServletConfig;)Lorg/apache/tomcat/InstanceManager; the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the current class, jsp/WEB_002dINF/jsp/home_005fpage_jsp, and the class loader (instance of java/net/URLClassLoader) for the method's defining class, org/apache/jasper/runtime/InstanceManagerFactory, have different Class objects for the type org/apache/tomcat/InstanceManager used in the signature at jsp.WEB_002dINF.jsp.home_005fpage_jsp._jspInit(home_005fpage_jsp.java:128) at org.apache.jasper.runtime.HttpJspBase.init(HttpJspBase.java:49) at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1231) Has anyone experienced/resolved this before?
RE: Java Heap Space / Thread Dump Numbers
// I think if you have vendor-locked app in vendor-locked environment (am I right?) // Yes indeed. // As I said above, there is an options for JVM: -XX:-HeapDumpOnOutOfMemoryError - it will make heapdump on OOM. -XX:HeapDumpPath=./java_pidpid.hprof - give it an reasonable path to file. Set this options to JVM, and it will make heapdumps automatically. // Will these heap dumps be the same size as the current tomcat memory utilization? // After you got an heapdump - you can look for biggest object in it, or give it to a vendor. What you are doind now - is a temperature measurement using something, that's not measure temperature. You are collect threaddump, but it's a where it was-state of app, but not what was in it-state. Imagine that something already occupies some size in memory. And some thread doing it's small job and tries to allocate a little size of memory. A small size, but there is no more free memory for allocation - this is a reason of OOM. From heapdump you can look what it was. // That sounds extremely promising. Now I'm starting to get excited. --Eric
Re: Java Heap Space / Thread Dump Numbers
2015-03-20 22:29 GMT+02:00 Eric Robinson eric.robin...@psmnv.com: Very good information. I much prefer finding the actual root causes of things rather than just bumping the memory, but I'm not sure how much that would help because the best I can do is report the issue to the vendor. Changing the code is off the table for me. If we can zero in on a problem, we may be able to get them to fix it. I think if you have vendor-locked app in vendor-locked environment (am I right?) - the bast way of fighting with OOMs will be looking into heaps. As I said above, there is an options for JVM: -XX:-HeapDumpOnOutOfMemoryError - it will make heapdump on OOM. -XX:HeapDumpPath=./java_pidpid.hprof - give it an reasonable path to file. Set this options to JVM, and it will make heapdumps automatically. After you got an heapdump - you can look for biggest object in it, or give it to a vendor. What you are doind now - is a temperature measurement using something, that's not measure temperature. You are collect threaddump, but it's a where it was-state of app, but not what was in it-state. Imagine that something already occupies some size in memory. And some thread doing it's small job and tries to allocate a little size of memory. A small size, but there is no more free memory for allocation - this is a reason of OOM. From heapdump you can look what it was. Threaddump on OOM is showing you what threads was not able to allocate some more memory in heap, and this may not be the thread which ate all memory. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue with Transfer-Encoding: chunked
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 3/20/15 12:12 PM, James Nord wrote: We have a webapp that when run with tomcat (7.0.52) on a certain host after a period of time has issues with chunking. The issue is that the terminating Zero length chunk is not sent by tomcat even though looking at the last chunk the data is complete. Whilst at first glance this would appear to be our webapp not finishing the request correctly tomcat initiates a TCP level close on the connection 20s after the last chunk has been sent. This 20s corresponds to the keepalive timout so it appears as though Tomcat thinks it is waiting for the next request to come from the client (and the client is still waiting for the terminating chunk). I have written a simple webapp with a servlet that behaves badily in various different ways I can image - and if the serverlet does not return from the doGet method then tomcat will not try and close the tcp connection and it remains open for a long time. We have ruled out network appliances/proxies/ssl and are seeing this when we talk directly to the tomcat http port. The more I look into this the more I think it appears to be a tomcat issue (we have had 3 reports of this and only when our app is run in Tomcat). I'm stuck now as to where I could possible look to get more information or if there is any extra logging in tomcat that I could enable around this area (I looked but didn't see any) to try and narrow the cause down to an area of Tomcat or our app. So I am reaching out with the hope that someone has some ideas... Is it possible for you to re-test with Tomcat 7.0.59? I don't see anything in the changelog that seems to apply directly, but this might be something that was fixed between 7.0.52 and 7.0.59. What connector are you using? Can you supply the (sanitized!) Connector configuration from the server.sml? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVDGmsAAoJEBzwKT+lPKRYcs0QAKTEg5uHymVqyHhc16FW8s6m ma3GVnGSJT3uj8XDEWqGkHgsGyA5nJeOOk5V1Kil0uyxSJIR1YcYjlUSOFPHM6w5 ldWZPNrRD7eW7Gmn4UyLBB8mXrBiNyLcUHrismpg0Mp7fPpOUvO/4GZqHei/e/kp b1kIEB4V4Ndh5xMp0ipb+Yt2n5W3b9sm2UwxBB5z478QiGX7UJ08jAaQeWGIjOL0 BcFhUCBoPCYgG16BSLSrP5oIm8766q/g8YbBSjgCbFU15uH6lLbNBvGVC1v6T57A LLNsZfy/djv3jYX+acFat56JfJdNI45mXrxKPeZtG8Jvn3C/BAfQMTqjlWIEfNsn Su9pmlE0ZarIsbM/Ymo4+HD0MIMDw+UyGq5JRMDA8O58cEoRUvSGa4ZSIdCQZd3y BPI4tqEFZX9qwOglj3nzcvHzafAhT+U22Sajw0D4mmRGF5gdorawHMfM9VCBXQyx nuJ4PnHDVS/fskQJORrxF0xf7DpOfHVr6BJvOLIMDHIWPqNL4br16ingXKPeYiW4 e0VaJgnQi4J2eUD2uk/U9rNZ7+ajqQgak3gjTBK1Tk2cTnloMjwayTvm/1vE4z1X JT+wUgvNVCLHjUypRCg6lWudkCY3/zSO+ctpDwQUqBNvmMoeqzjkHiOxMjg5ni7A L3SDn3t51DDaTiizm+Sd =JEhZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Java Heap Space / Thread Dump Numbers
2015-03-20 1:15 GMT+02:00 Eric Robinson eric.robin...@psmnv.com: Heap dumps? What we do is called a thread dump, as far as I know. We use kill -3 on Linux, which dumps the thread activity. The memory data shows up at the bottom of that. See: http://producthelp.sdl.com/WorldServer/10.2/en/GUID-4F09CD10-BC4F-46A8-AE83-599A5C8C7740.html Yeah, heapdumps. I've posted above some howtos, have you looked at them? //Sorry for previous top-posting, I still can't get used to bottom-posting into mailing lists :( - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat8 gives me WSOD due to LinkageError
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Neill, On 3/20/15 4:58 AM, Neill Lima wrote: I have a existing WebApp that I'm planning to upgrade to Tomcat8 (version 8.0.20 as of today). It is running stable in Tomcat7 already for ages. Great. Tomcat8 does not embed the JasperListener so I added it manually to my pom.xml otherwise I was getting NoClassDefFoundError. Wait, what? What do you mean Tomcat8 does not embed the JasperListener? What are you actually trying to do? Just run a JSP? It should work out of the box without any Maven foolishness. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVDEXwAAoJEBzwKT+lPKRYQsUQAJjQDrBPvSP5mEg8IsME5kDz Y39SDR5I0XQ0cLM3IIgCCFKpfTU71gvbLdJflQSz6JU833iye2E515IijKnlnINr 0FiJ1E2ogKLJWfmhu28f0VWFXJ3Dy+qSL2AT1H4yF8ed+JTfXWFkzKzkoxSuXeMn TKBTUxXfD7f4ei9EEK3ZEDvWUIJ7w6v4gBJ8BriOZ9/iLYTiZ9S90KL/ilp4Iypw 2/ncET7WqoLqshM4g+fswEeSjOeEQn5J50gebqubUxhsmfUt+BYXGDIchAc8yUVp MTjJw5r9QpOCgeNyuMdK4Vg/DCcgsTzhHT7rcYh1iItwckqpcr04rc/AlYFnEU/u 78MzHR6U0iIAx49tWb6bwRbsjnygFKPHX49dAlhmdopijuNumrl6yvmUyR5fTA8d RNvcXbHhMm06SesW7QvkUPZk8Qq6W/2WBH+kKuMMmBXzJt0p7XG3BvgtTqLwBUDj 7oGli1p8JsV0pg/pYERW4lpNuDg1LsLuzCg1EvRJ7wuoN6j1k47uL6c7dNw4QdFE p6DpKpeCZH85y4CCupqexwmhut/OYIF2F6W2NMBgn78SfY8HD51FrBnb9zeiq1Gr PgeitwooTzyafWNAvNbPv2TUO6qXzvrY6+eA2UurizMYN30ir3tDh+IwcYNG7OtW bcIjoFmirZ36tYJIgwn1 =wbJX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Java Heap Space / Thread Dump Numbers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Eric, On 3/19/15 7:15 PM, Eric Robinson wrote: Christopher Shultz wrote: // Time to upgrade. Tomcat is hideously out of date (probably because you are using RedHat's Tomcat package), at least by version number. I'm not sure what RedHat does (if anything) about security fixes, etc. but a vanilla 6.0.18 is probably vulnerable and has been for a very long time. Java 1.6 is EOL and Java 1.7 is getting close. I strongly advise you to move up to Tomcat 8.0.20 and Java 1.8 and start developing and testing your application against those versions. // Would if I could. Vendor restriction. I can only run what they will support. Bah. I hate Vendors. Tell them to get with the program. What you are getting isn't support: it's complacency. If someone hacks your environment, they would certainly start paying attention. You should hire another vendor to do penetration tests and let the sparks fly. Christopher Shultz wrote: // Typical startup options looks like this... JAVA_OPTS=-Xms192M -Xmx384M \ -XX:MaxPermSize=128M \ Those seem reasonable, except maybe not PermGen. Are you increasing it or reducing it from the default on your platform? // Increased from default of 64 MB, which ran fine for years until a recent software upgrade. Okay. Christopher Shultz wrote: // The memory allocation seems low to you because we run many instances of tomcat on the same server. Although the servers have 32-64GB of RAM, the individual tomcat/java instances are kept fairly low. We ran for years in a 64MiB heap. Then we got enough traffic that sessions required us to expand our heaps. If you can run in a small heap, great. But keep your eye on what's happening with your users; you may find that you have outgrown your old heap settings. // That's what this question is about. We ran 64 MB heaps for years, but with the latest application software version we find that 192-384 is required per instance. Others throw errors unless they get 768. We cannot set them all the same, so we need to configure them very carefully and closely. Recent 64-bit JVMs will automatically use -XX:+UseCompressedOops. I'm not sure about your version, specifically. If you have the option, you might want to run a 32-bit JVM; it will probably run leaner and faster than a 64-bit JVM will. Christopher Shultz wrote: // We are trying to be proactive by watching the memory usage numbers in the thread dumps. Heap dumps? // What we do is called a thread dump, as far as I know. We use kill -3 on Linux, which dumps the thread activity. The memory data shows up at the bottom of that. See: http://producthelp.sdl.com/WorldServer/10.2/en/GUID-4F09CD10-BC4F-46A8-AE83-599A5C8C7740.html Okay. A heap dump produces a file roughly the size of the heap space. You are getting a heap summary. If you are issuing a kill -3 and then looking at stdout, I'd encourage you to take a look at jstack which can do the same thing (dump the thread status) but it can be redirected to some other file. That is, it doesn't dump to the target JVM's stdout, but the jstack tool's stdout. It's much more convenient. If you are looking for heap information, you want jmap instead: $ jmap -heap [pid] Unfortunately, each of these tools produces output in a slightly different format, so you may have to adjust some of your automated tools to suit. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVDEVSAAoJEBzwKT+lPKRYmNMP/is3AWqp7ZaHccFFQ2olE9su 51SmM1iLsQz9d0KhpXZtC7JK0l7pzE0roxhiAZEHmhg+nmWNRY8nCzcNvT4BM3P2 WUJnakmGve2gvziHXOH/bhtWdsODYCHm/rdxMHUYf+9i2i4aKwpBG0KtVHzK3f3r 29oC17hqzE2IqRSLaWKSM3xLY4smXVBb29srKnhjL86k4pPtRisdI9beCRTRagoo D4tcWK/vre6r+0Hq50bj2oM7ECCpNnWVv/TloKy18DsuyU1ODsTE9XWoBKuMVSry HYiStjGB0wHuiltwF5Q7PtVH+gAMJTFYExUekMFOt4nESllcZw6bezZnbPm2Q2Qd AJkLvA2SRgRBEzXUFkbWozlSCIDz/kKNAYYd9mzAJQDwRrvaoumACYbOdyBWApZM xC+bIb2rgVvXKHZr0cbzEmfoXRq3bHSfI3rMCpj2lY7PCjLw9jFukuc+ogiuiPbu HgkfyFofJKOAYp2aimbzH4RBGzddDh0gm3VD7kOUHudyWngH2UmUtwHcdOmH/Jtw MFK99lhQ+5Mdxg1Damb4nZxmfWWmQkHOV8pvNBw/pyWFIEo73QO3L4T0ZTAZM3Ll CpqAPiWKTWzEBGE3hL1PWB9DKbWTTeZjDFOwJ/gKW8Gcb8y8RKq41EL4yzRc8lWu QCoidw6zb75NIrXYuXd3 =8EKS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat8 gives me WSOD due to LinkageError
Hello Chris, As of today I figured out that the jasper.jar in Tomcat's \lib takes care of the task out of the box. I've tweaked my pom a few times, but I started fresh today and realized it. So no pom updates were necessary. Still I'm getting this exception I mentioned in the earlier e-mail: Caused by: java.lang.LinkageError: loader constraint violation: when resolving method org.apache.jasper.runtime.InstanceManagerFactory.getInstanceManager(Ljavax/servlet/ServletConfig;)Lorg/apache/tomcat/InstanceManager; the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the current class, jsp/WEB_002dINF/jsp/home_005fpage_jsp, and the class loader (instance of java/net/URLClassLoader) for the method's defining class, org/apache/jasper/runtime/InstanceManagerFactory, have different Class objects for the type org/apache/tomcat/InstanceManager used in the signature at jsp.WEB_002dINF.jsp.home_005fpage_jsp._jspInit(home_005fpage_jsp.java:128) at org.apache.jasper.runtime.HttpJspBase.init(HttpJspBase.java:49) at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1231) It does not happen on my current Tomcat7 deploy though. On Fri, Mar 20, 2015 at 5:08 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Neill, On 3/20/15 4:58 AM, Neill Lima wrote: I have a existing WebApp that I'm planning to upgrade to Tomcat8 (version 8.0.20 as of today). It is running stable in Tomcat7 already for ages. Great. Tomcat8 does not embed the JasperListener so I added it manually to my pom.xml otherwise I was getting NoClassDefFoundError. Wait, what? What do you mean Tomcat8 does not embed the JasperListener? What are you actually trying to do? Just run a JSP? It should work out of the box without any Maven foolishness. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVDEXwAAoJEBzwKT+lPKRYQsUQAJjQDrBPvSP5mEg8IsME5kDz Y39SDR5I0XQ0cLM3IIgCCFKpfTU71gvbLdJflQSz6JU833iye2E515IijKnlnINr 0FiJ1E2ogKLJWfmhu28f0VWFXJ3Dy+qSL2AT1H4yF8ed+JTfXWFkzKzkoxSuXeMn TKBTUxXfD7f4ei9EEK3ZEDvWUIJ7w6v4gBJ8BriOZ9/iLYTiZ9S90KL/ilp4Iypw 2/ncET7WqoLqshM4g+fswEeSjOeEQn5J50gebqubUxhsmfUt+BYXGDIchAc8yUVp MTjJw5r9QpOCgeNyuMdK4Vg/DCcgsTzhHT7rcYh1iItwckqpcr04rc/AlYFnEU/u 78MzHR6U0iIAx49tWb6bwRbsjnygFKPHX49dAlhmdopijuNumrl6yvmUyR5fTA8d RNvcXbHhMm06SesW7QvkUPZk8Qq6W/2WBH+kKuMMmBXzJt0p7XG3BvgtTqLwBUDj 7oGli1p8JsV0pg/pYERW4lpNuDg1LsLuzCg1EvRJ7wuoN6j1k47uL6c7dNw4QdFE p6DpKpeCZH85y4CCupqexwmhut/OYIF2F6W2NMBgn78SfY8HD51FrBnb9zeiq1Gr PgeitwooTzyafWNAvNbPv2TUO6qXzvrY6+eA2UurizMYN30ir3tDh+IwcYNG7OtW bcIjoFmirZ36tYJIgwn1 =wbJX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Issue with Transfer-Encoding: chunked
Hi all, We have a webapp that when run with tomcat (7.0.52) on a certain host after a period of time has issues with chunking. The issue is that the terminating Zero length chunk is not sent by tomcat even though looking at the last chunk the data is complete. Whilst at first glance this would appear to be our webapp not finishing the request correctly tomcat initiates a TCP level close on the connection 20s after the last chunk has been sent. This 20s corresponds to the keepalive timout so it appears as though Tomcat thinks it is waiting for the next request to come from the client (and the client is still waiting for the terminating chunk). I have written a simple webapp with a servlet that behaves badily in various different ways I can image - and if the serverlet does not return from the doGet method then tomcat will not try and close the tcp connection and it remains open for a long time. We have ruled out network appliances/proxies/ssl and are seeing this when we talk directly to the tomcat http port. The more I look into this the more I think it appears to be a tomcat issue (we have had 3 reports of this and only when our app is run in Tomcat). I'm stuck now as to where I could possible look to get more information or if there is any extra logging in tomcat that I could enable around this area (I looked but didn't see any) to try and narrow the cause down to an area of Tomcat or our app. So I am reaching out with the hope that someone has some ideas... Thanks in advance /James - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Java Heap Space / Thread Dump Numbers
From: Eric Robinson [mailto:eric.robin...@psmnv.com] Subject: RE: Java Heap Space / Thread Dump Numbers If you have the option, you might want to run a 32-bit JVM; it will probably run leaner and faster than a 64-bit JVM will. What do you mean my faster and leaner? Mostly leaner - a 32-bit JVM uses 32-bit pointers, so object references consume less heap and stack space. Whether or not the code runs faster or slower depends on what you're doing, since the tradeoff is fewer registers available in 32-bit mode, which can lead to more register spills and reloads. Testing of the specific webapps is required. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Java Heap Space / Thread Dump Numbers
// You can look for biggest objects in heap (using MAT, Leak Suspects report, Dominators Tree report). This way you can try to find what was the exact reason of OOM instead of just thinking eh, I need to give instances more memory. MAT does things good. I've already found using MAT+JVVM the reasons why my instances of two different apps die with OOM (and only one of that reasons was 3rd party library, others was not well written code). Now I'm looking to make optimisations and shrink memory for instances a lot. That's my sucess story :) // Very good information. I much prefer finding the actual root causes of things rather than just bumping the memory, but I'm not sure how much that would help because the best I can do is report the issue to the vendor. Changing the code is off the table for me. If we can zero in on a problem, we may be able to get them to fix it. --Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6-8 upgrade breaks logout script?
I hope someone may be able to provide some insight or a solution to a problem we encountered after I upgraded from Tomcat 6 to 8. We're using Tomcat as the servlet container for our Shibboleth IdP SSO, which we use to authenticate to Google Apps. Google allows you to configure a URL used for logout. We have this pointed at a logout.jsp page that basically does the following (excerpted code cribbed from the shibboleth-users list): https://groups.google.com/forum/#!msg/shibboleth-users/CFkau-FHCsA/yx7KRO9xMCoJ - Cookie c; c = new Cookie(JSESSIONID, null); c.setPath(/idp); c.setMaxAge(0); response.addCookie(c); c = new Cookie(_idp_session, null); c.setPath(/idp); c.setMaxAge(0); response.addCookie(c); session.invalidate(); - This was working until I upgraded from Tomcat 6 to Tomcat 8. Since then, the cookies no longer seem to get wiped. Users are still logged in if they revist any of the Google Apps. Any suggestions or pointers on how to get this working again would be most appreciated. Aloha, -baron -- Baron Fujimoto ba...@hawaii.edu :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Java Heap Space / Thread Dump Numbers
// Mostly leaner - a 32-bit JVM uses 32-bit pointers, so object references consume less heap and stack space. Whether or not the code runs faster or slower depends on what you're doing, since the tradeoff is fewer registers available in 32-bit mode, which can lead to more register spills and reloads. Testing of the specific webapps is required. // Worth trying it anyway. It's an easy test. --Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Java Heap Space / Thread Dump Numbers
// Yeah, heapdumps. I've posted above some howtos, have you looked at them? // No, I'm not sure how useful I would find them. I think the heap summary is probably all I need, but I may be wrong. Would the heap dump provide more actionable intel as far as tuning my memory parameters? --Eric
RE: Java Heap Space / Thread Dump Numbers
// Recent 64-bit JVMs will automatically use -XX:+UseCompressedOops. I'm not sure about your version, specifically. If you have the option, you might want to run a 32-bit JVM; it will probably run leaner and faster than a 64-bit JVM will. // Interesting. What do you mean my faster and leaner? We're currently running 60-90 instances of tomcat on 8-core servers with 32-64GB RAM, and they all run fast. Swapping is negligible, CPU is around 20% average utilization, iowait is low. The only time we have trouble is when an instance occasionally runs out of memory and throws an OOME. When that happens, we allocate another 64MB to that instance and restart it. // If you are issuing a kill -3 and then looking at stdout, I'd encourage you to take a look at jstack which can do the same thing (dump the thread status) but it can be redirected to some other file. That is, it doesn't dump to the target JVM's stdout, but the jstack tool's stdout. It's much more convenient. If you are looking for heap information, you want jmap instead: $ jmap -heap [pid] Unfortunately, each of these tools produces output in a slightly different format, so you may have to adjust some of your automated tools to suit. // Great info, thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Java Heap Space / Thread Dump Numbers
2015-03-20 22:09 GMT+02:00 Eric Robinson eric.robin...@psmnv.com: I've posted above some howtos, have you looked at them? No, I'm not sure how useful I would find them. I think the heap summary is probably all I need, but I may be wrong. Would the heap dump provide more actionable intel as far as tuning my memory parameters? You can look for biggest objects in heap (using MAT, Leak Suspects report, Dominators Tree report). This way you can try to find what was the exact reason of OOM instead of just thinking eh, I need to give instances more memory. MAT does things good. I've already found using MAT+JVVM the reasons why my instances of two different apps die with OOM (and only one of that reasons was 3rd party library, others was not well written code). Now I'm looking to make optimisations and shrink memory for instances a lot. That's my sucess story :) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Java Heap Space / Thread Dump Numbers
From: Eric Robinson [mailto:eric.robin...@psmnv.com] Subject: RE: Java Heap Space / Thread Dump Numbers Would the heap dump provide more actionable intel as far as tuning my memory parameters? It would provide information about what types of objects are consuming the heap space. From that, you may be able to adjust your webapp's settings to avoid running into trouble (or modify the webapp, if it's abusing the heap). If you monitor the heap usage on a regular basis (e.g., once an hour), you might be able to see if the webapp is leaking memory. Also, by comparing the heap dumps with the current request load, you might get an idea of just how large you need to make the heap to satisfy your peak periods. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6-8 upgrade breaks logout script?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Baron, On 3/20/15 4:27 PM, Baron Fujimoto wrote: I hope someone may be able to provide some insight or a solution to a problem we encountered after I upgraded from Tomcat 6 to 8. We're using Tomcat as the servlet container for our Shibboleth IdP SSO, which we use to authenticate to Google Apps. Google allows you to configure a URL used for logout. We have this pointed at a logout.jsp page that basically does the following (excerpted code cribbed from the shibboleth-users list): https://groups.google.com/forum/#!msg/shibboleth-users/CFkau-FHCsA/yx7KRO9xMCoJ - - Cookie c; c = new Cookie(JSESSIONID, null); c.setPath(/idp); c.setMaxAge(0); response.addCookie(c); c = new Cookie(_idp_session, null); c.setPath(/idp); c.setMaxAge(0); response.addCookie(c); session.invalidate(); - This was working until I upgraded from Tomcat 6 to Tomcat 8. Since then, the cookies no longer seem to get wiped. Users are still logged in if they revist any of the Google Apps. Any suggestions or pointers on how to get this working again would be most appreciated. Try adding a trailing / onto the end of the path: c.setPath(/idp/); - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVDJVCAAoJEBzwKT+lPKRYVSIP/3Z/oE5k8zaG+rjq9nfTpHFL LQ4BivQ1AHtNczZNk4CrtpWC2+ae1FhWFCYTB4IVqd2ZaS1Iah7DDVGgbwdF0ZBv TJT5l76C+wSpC4GQqZ6mlkkUn0KjC8OqWC5oJQ4Fk3zfJXZ4mfxrK55ApptZUAaY Nh1aDAcGDiomKKuNHCaQz1Q4CTBNNpMSRLN7XsRPCh/WZVMMDIlZVDTEkTB/mmid 5AxrWUnSeAaDuN3Koa54N2XrasvdW4mBSA/41GGOCu11awoDoQD3ss9lq3ruV64K X+YiBRDkUmGB6sKrxdu2mA8wEr2+8UeY6/VbIcg6p/iujx2iLV26d6z/t3FsBMDa vmtzlFtciHqiLCeD8yNaCTKRq02pfN5VmugXtO4GrTjn2ytXasMtCtOBm53XokeL m4iyKtFpziNqK4qhB6kF2VjvA2aAq17+ub9NsCWYI7l+lEuXtoxT2EvLrzliUPNH KDa7dBYD4+os00iaBlWUaL6SmPMGH1es2sh6OK17o+0bDVjAV1OIZaFrhyKb3FJn eew0rxK5SJIlxexaSwuDU1LNKdnDd8g3qRvf1SBNP/MMi/FH9nNK6lcsE3vB14Xc 7hL5Wcgi1/Mdh5PZsfwtBTz8OyjQ+khcuK6ZF2CAJTOr98JPLIy2/RrdAwgDJeHM oR8IZ/Da2ZrwvqUG8oQr =WzOR -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: org.apache.jasper.JasperException: The absolute uri: http://tiles.apache.org/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application
Hi,
Hi Chris,
Thanks a lot for the quick response. Please find inline answers.
On 3/18/15 5:39 AM, Thusitha Thilina Dayaratne wrote:
I'm in the process of migrating embedded tomcat 7.0.59 application
to Tomcat 8.0.20. Tomcat is been bundle as a OSGI bundle. First I
get a NullPointerException when trying to access the server home
page. I fixed that manually setting an empty TldCache instance in
the context as follows
[snip]
Now it is not throwing the NPE. but instead of that I'm getting
following exception
org.apache.jasper.JasperException: The absolute uri:
http://tiles.apache.org/tags-tiles cannot be resolved in either
web.xml or the jar files deployed with this application at
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55)
I
looks like you are missing the Tiles JAR. Is it located in your
WEB-INF/lib directory?
These jar files are located in a folder called plugins. We are reading
them
from our JarScanner
I'm also using a extended JarScanner as follows
public class CarbonTomcatJarScanner extends StandardJarScanner{
Without trying to read and understand all this code, can you explain
why you are using your own JarScanner instead of Tomcat's? Perhaps
there is a way to do this where you don't need to write your own
JarScanner.
According the servlet 3.0 spec, tldScanner classes are picked up
during web-app load phase from
the classPath using SPI mechanism. Normal sequence is to scan;
- WEB-INF/lib
- parent URL classPath
However with the BundleClassLoader being the parent classLoader of
Tomcat web-app classLoder, it fails to pick up
TLD scanner references reside in plugins directory. That is why we
have used a our own JarScanner
It seems that this is relate to JarScanner. Can someone tell me
what I have done wrong here? Or a way to fix this? Is this occur
because I set TldCache manually?
I'm curious as to why the TldCache isn't being set up correctly in the
first place. In your other recent thread (NPE in
JspCompilationContext.getTldResourcePath), there were a couple of
questions from the community that it doesn't look like you have
answered. Perhaps answering those might help you solve both problems
at once.
I'm not so quite sure about that. I manually set the TldCache and manually
added the JasperInitializer to the StandardContext
to get rid of the NPE
I will try to answer the an answered questions in other thread.
You may want to have a look at Eclipse Gemini Web (OSGi Web Container
Reference Implementation)
Thanks for the reference. We are using eclipse equinox jasper. Could that
be a reason that TldCache not getting initialized?
Thanks
Best Regards
/Thusitha
On Fri, Mar 20, 2015 at 12:00 AM, Violeta Georgieva miles...@gmail.com
wrote:
Hi,
2015-03-19 5:34 GMT+02:00 Thusitha Thilina Dayaratne thusit...@wso2.com:
Hi Chris,
Thanks a lot for the quick response. Please find inline answers.
On 3/18/15 5:39 AM, Thusitha Thilina Dayaratne wrote:
I'm in the process of migrating embedded tomcat 7.0.59 application
to Tomcat 8.0.20. Tomcat is been bundle as a OSGI bundle. First I
get a NullPointerException when trying to access the server home
page. I fixed that manually setting an empty TldCache instance in
the context as follows
[snip]
Now it is not throwing the NPE. but instead of that I'm getting
following exception
org.apache.jasper.JasperException: The absolute uri:
http://tiles.apache.org/tags-tiles cannot be resolved in either
web.xml or the jar files deployed with this application at
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55)
I
looks like you are missing the Tiles JAR. Is it located in your
WEB-INF/lib directory?
These jar files are located in a folder called plugins. We are reading
them
from our JarScanner
I'm also using a extended JarScanner as follows
public class CarbonTomcatJarScanner extends StandardJarScanner{
Without trying to read and understand all this code, can you explain
why you are using your own JarScanner instead of Tomcat's? Perhaps
there is a way to do this where you don't need to write your own
JarScanner.
According the servlet 3.0 spec, tldScanner classes are picked up
during web-app load phase from
the classPath using SPI mechanism. Normal sequence is to scan;
- WEB-INF/lib
- parent URL classPath
However with the BundleClassLoader being the parent classLoader of
Tomcat web-app classLoder, it fails to pick up
TLD scanner references reside in plugins directory. That is why we
have used a our own JarScanner
It seems that this is relate to JarScanner. Can someone tell me
what I have done wrong here? Or a way to fix this? Is this occur
because I set TldCache manually?
I'm curious as to why the TldCache isn't being set up correctly in the
first place. In your other
