Suggestions for really getting to the bottom of memory leak issues on hot-deploys
Here's what I did and what little I came up with: http://stufftohelpyouout.blogspot.com/2011/05/diagnosing-webappportlet-hot-deploy.html I'm definitely not an expert at diagnosing leaks, so if you have any recommendations/comments, please let me know. I unfortunately started off just thinking I could tune JVM settings, not just by bumping up permgen but by adding things like: -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled But, I was (really) wrong as you can see in the post, along with the various tools used to try to identify what was causing the issue(s). It doesn't seem like determining exactly what is leaking memory (at least in the case of permgen and hot-redeploys/hot-deploys) is a whole lot easier than it was years ago, unless I'm doing something wrong, which I most likely am. Thanks in advance for any feedback! Gary
Re: Suggestions for really getting to the bottom of memory leak issues on hot-deploys
Chris, On Tue, May 10, 2011 at 4:06 PM, Christopher Schultz ch...@christopherschultz.net wrote: http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf Thanks! That is a great presentation! Gary
Peering into the pit of jar hell - the mess of tomcat's and other jars in RPM distributions
Sorry to open up with venting, but I truly cannot believe how big of a mess that I found of Tomcat's and others' jars under /usr/share/java in a CentOS 5.2 distribution I examined this morning. For years I've been using tar.gz'd Tomcat that I downloaded and applications I used that had standalone installs would provide similar looking directory layouts of Tomcat. All of those were just great. In the RPM'd Tomcat though, the directories are spread out all over the place (which is acceptable), but from what I've been told, the backporting of patches and possibly attempts to lower the number of the same files (jar files in this case) leave you with a ton of sometimes insane looking symlinks and files. Here is what I'm talking about in /usr/share/java if you're unfamiliar: libgcj-4.1.1.jar libgcj-4.1.2.jar - libgcj-4.1.1.jar libgcj-tools-4.1.1.jar libgcj-tools-4.1.2.jar - libgcj-tools-4.1.1.jar Regardless of how trivial a small change in a version of a jar might be in one case for one version of an application, since this is a shared area for jars, you don't know what some other application would expect out of that jar. And if the person trying to track down an issue thinks they are using one version of a jar, but it is really pointed at a different version. xerces-j2.jar - xerces-j2-2.7.1.jar This seems wrong because you can't assume that, just because you are dependent on a certain jar in one application, the same one would apply to multiple applications. One app might be built with 2.7.1 and another with 2.7.3 that didn't deprecate some method that it removed or changed the signature of, and you might not notice that unless every facet of the jar were tested, and if RedHat or the Fedora community has enough time to do that, they certainly aren't spending their time very wisely. wsdl4j.jar - qname-1.5.2.jar This just looks completely wrong, even if they completely merged the same version of the previous jar into the new one: and servletapi5.jar - tomcat5-servlet-2.4-api-5.5.23.jar This seems wrong on a new counts here as it is a specific implementation and specific version paired with a generic jar name symlink. this one is more excusable than the others though. I don't fundamentally disagree with things often, but I really don't agree that this is a good idea, and it is unfortunately one of the worst messes of jars/dependencies I've seen in my last 10 years as a Java developer (and I've seen some pretty messed up things). How and why could someone RPM Tomcat at all if this is the mess that it falls into? TIA for any comments, facts, or opinions you can provide, Gary Please note that I also just wrote a quick entry about this here (feel free to comment there if you'd rather, although they shut it down for comments after a while to avoid blog link spamming): http://weblogs.java.net/blog/garysweaver/archive/2009/05/peering_into_th.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Peering into the pit of jar hell - the mess of tomcat's and other jars in RPM distributions
Martin, Thanks much for the time you spent on the explanation. However (and hopefully I'm being brief also)- one of issues in doing this is that wsdl4j.jar could (in-general) be any version of wsdl4j not necessarily something that just happens to be populated with one or more classes that do nothing more than have methods that just then call classes in (version specific, because method signatures/classes/packages could change in diff versions) qname-1.5.2.jar. (This is - if that is what you are saying- I do not know what version of wsdl4j it is here, nor have I looked at the source, since I don't know what version it is from the name). The impression I get from looking at the mess of symlinks is that people are assuming (like vendors of Windows products that contributed to Microsoft's DLL hell starting mostly in Win95) that playing around with filenames and versions is perfectly acceptable if it gets the job done (for reducing space they take up in an attempt to share files, or in this case possible reducing the stack level by bypassing methods in an interface jar completely). But in fact, when this is done the only substantial good it does that is not outweighed by negatives is that RedHat will end up selling more support licenses for people that get fed up with RPMs on CentOS/Fedora not working properly (after all, they make money off of support, right?). That maybe a fatalistic viewpoint on my part, and I don't mean to start a firestorm, but basically (in this case) unless you were to have a directory that contained a bunch of jars where each filename were to have a version that actually corresponds to the well-known version of that specific jar, then I think you are really asking for trouble. Thanks, Gary Martin Gainty wrote: MGGood Afternoon Gary MG(hopefully brief) comment annotations displayed below Martin __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Fri, 22 May 2009 15:01:37 -0400 From: gary.wea...@duke.edu To: users@tomcat.apache.org Subject: Peering into the pit of jar hell - the mess of tomcat's and other jars in RPM distributions Sorry to open up with venting, but I truly cannot believe how big of a mess that I found of Tomcat's and others' jars under /usr/share/java in a CentOS 5.2 distribution I examined this morning. For years I've been using tar.gz'd Tomcat that I downloaded and applications I used that had standalone installs would provide similar looking directory layouts of Tomcat. All of those were just great. In the RPM'd Tomcat though, the directories are spread out all over the place (which is acceptable), but from what I've been told, the backporting of patches and possibly attempts to lower the number of the same files (jar files in this case) leave you with a ton of sometimes insane looking symlinks and files. Here is what I'm talking about in /usr/share/java if you're unfamiliar: libgcj-4.1.1.jar libgcj-4.1.2.jar - libgcj-4.1.1.jar libgcj-tools-4.1.1.jar libgcj-tools-4.1.2.jar - libgcj-tools-4.1.1.jar Regardless of how trivial a small change in a version of a jar might be in one case for one version of an application, since this is a shared area for jars, you don't know what some other application would expect out of that jar. And if the person trying to track down an issue thinks they are using one version of a jar, but it is really pointed at a different version. xerces-j2.jar - xerces-j2-2.7.1.jar This seems wrong because you can't assume that, just because you are dependent on a certain jar in one application, the same one would apply to multiple applications. One app might be built with 2.7.1 and another with 2.7.3 that didn't deprecate some method that it removed or changed the signature of, and you might not notice that unless every facet of the jar were tested, and if RedHat or the Fedora community has enough time to do that, they certainly aren't spending their time very wisely. wsdl4j.jar - qname-1.5.2.jar
Re: in Tomcat container-based authN is there a way to redirect logins to a URL?
Chris, In the version of Tomcat I'm using 5.5.25, when I do what you are suggesting, and set the config to: login-config auth-methodFORM/auth-method realm-namedemo/realm-name form-login-config form-login-page/Shibboleth.sso/Login/form-login-page form-error-page/Shibboleth.sso/Login/form-error-page /form-login-config /login-config I get the following error, because those two page elements are relative to the webapp and not to the host part of the URL: HTTP Status 404 - /caladmin/Shibboleth.sso/Login *type* Status report *message* _/caladmin/Shibboleth.sso/Login_ *description* _The requested resource (/caladmin/Shibboleth.sso/Login) is not available._ Apache Tomcat/5.5.25 I need it to redirect to /Shibboleth.sso/Login instead of /(webapp)/Shibboleth.sso/Login. Any idea how I could do that in Tomcat 5.5.x? Thanks! Gary Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary, Gary Weaver wrote: | I'm having trouble finding a way (maybe it is because it isn't | possible?) of making Tomcat send users to the relative URL | /Shibboleth.sso/Login (not served by Tomcat) in order to login if | the Tomcat session times out, etc. Does it work to simply make your application's form-login-page point to /Shibboleth.sso/Login? If you do that, what happens? | Does anyone know of a way to redirect Tomcat to point at some other | URL, specifically the relative URL /Shibboleth.sso/Login (not | served by Tomcat)? I think some versions of Tomcat do a server-side forward when the login form is required, while other versions will do a redirect. If you can get Tomcat to do a redirect, this ought to work. If it's attempting to do a server-side forward, you may have to take other steps. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkerHjgACgkQ9CaO5/Lv0PDEewCgsaWxeBEsPBa8VLQ4Ut8Y687c 5gYAn2IC0OWh7LTtZMq01y5jB07YI+Xp =cEAC -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gary Weaver Internet Framework Services Office of Information Technology Duke University - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Container-based authentication and Shibboleth SSO - issue with redirecting login to Shibboleth after session timeout
Hello, We're having a timeout issue (probably configuration) with Tomcat 5.5.25 and Shibboleth 1.3f ( http://shibboleth.internet2.edu/ ). The environment is a dev server setup such that the Shibboleth SP is integrated with Apache 2.0.52 via mod_shib which is in turn using Tomcat (via AJP/JK). Bedework (event calendar) is using Tomcat's built-in authN which has been configured to use Shibboleth for authN via the method described at: https://spaces.internet2.edu/display/SHIB/ShibbolizedBedework (Bedework uses container-based authentication as defined by the Java servlet specification. There is no authentication code within Bedework.) The issue is that when user authenticates to Bedework (via Shibboleth) and leaves their browser open for a long time (over the weekend), instead of getting the Shibboleth login screen when they return and attempt to access a page in Bedework that requires authN, the user gets the grey Tomcat (default) login screen which won't let them login (because authN is only allowed via the Shibboleth SSO). If the user closes the browser (or clears cache/cookies/authenticated sessions) and tries the page again, they get the Shibboleth login (as we intended them to get). Below are (hopefully the) relevant Tomcat and Shibboleth SP config settings on the dev server that displayed this issue. Do any of these look suspicious/wrong? Sent this to the Shibboleth and Bedework user mailing list as well as our local Shib guy, and collectively they think is not Shib or Bedework but is something with the Tomcat config. Mike Douglass (lead Bedework developer) said My guess is you might need to disable servlet container login processing and ensure that shibboleth will always catch unauthenticated sessions and do its thing. It's also possible there are hooks in tomcat to redirect login processing to something like shibboleth. Mattias Amnefelt (another Bedework user) said If you could try using the request dumper valve to see if you actually have REMOTE_USER set that would help the debugging. If it's set when the request comes to tomcat then it's definitely not a shibboleth issue. I noticed also that two of the web.xml's for the webapps in Bedework define login and (login) error pages for form auth-method, and another is configured for basic auth-method. I could possibly override those form configs in our Bedework repackaging build to point at Shibboleth SP login paths, but if there is an easy way to both get the session timeouts and maybe the login URL redirect set correctly in local tomcat config (tomcat/conf/) maybe that would be better. If you have any ideas, please let me know. Thanks in advance! -- Gary Weaver Internet Framework Services Office of Information Technology Duke University Configuration: shibboleth.xml: ... !-- See Wiki for details: cacheTimeout - how long before expired sessions are purged from the cache AATimeout - how long to wait for an AA to respond AAConnectTimeout - how long to wait while connecting to an AA defaultLifetime - if attributes come back without guidance, how long should they last? strictValidity - if we have expired attrs, and can't get new ones, keep using them? propagateErrors - suppress errors while getting attrs or let user see them? retryInterval - if propagateErrors is false and query fails, how long to wait before trying again Only one session cache can be defined. -- MemorySessionCache cleanupInterval=300 cacheTimeout=3600 AATimeout=30 AAConnectTimeout=15 defaultLifetime=1800 retryInterval=300 ... ... (under Applications) Sessions lifetime=7200 timeout=3600 ... ... tomcat config: tomcat/conf/server.xml: ... Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase allRolesMode=authOnly / ... (session timeout in minutes) tomcat/conf/web.xml: session-timeout30/session-timeout (Bedework) webapp configs: webapps/ucal/WEB-INF/web.xml: login-config webapps/ucal/WEB-INF/web.xml:auth-methodFORM/auth-method webapps/ucal/WEB-INF/web.xml:realm-namedemo/realm-name webapps/ucal/WEB-INF/web.xml:form-login-config webapps/ucal/WEB-INF/web.xml: form-login-page/docs/login/login.html/form-login-page webapps/ucal/WEB-INF/web.xml: form-error-page/docs/login/error.html/form-error-page webapps/ucal/WEB-INF/web.xml:/form-login-config webapps/ucal/WEB-INF/web.xml: /login-config -- webapps/caladmin/WEB-INF/web.xml: login-config webapps/caladmin/WEB-INF/web.xml:auth-methodFORM/auth-method webapps/caladmin/WEB-INF/web.xml:realm-namedemo/realm-name webapps/caladmin/WEB-INF/web.xml:form-login-config webapps/caladmin/WEB-INF/web.xml: form-login-page/docs/login/login.html/form-login-page webapps
