Re: IS that a good idea moving all the common libs?
On 21/12/2010 23:49, George Sexton wrote: -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Monday, December 20, 2010 1:08 PM To: Tomcat Users List Subject: Re: IS that a good idea moving all the common libs? On Dec 20, 2010, at 12:16, Luca Gervasi tom...@ashetic.net wrote: I'm trying to lower the permgen needed by a large amount of webapps moving all the commonly used libs to the tomcat common libs. That's a really, really bad idea. You would be intertwining all your webapps, potentially introducing object leaks across webapps, and creating insurmountable versioning issues. You'd also require a complete Tomcat restart to update any single webapp. I'm really not seeing that. Anyhow, would the suggestion change if you were running 300+ web applications? It is do-able if you are prepared to accept the associated constraints: - all web apps must use the exact same version of every shared library - updating the shared libraries requires a Tomcat restart - all of the shared web apps must be well behaved in a multiple class-loader environment - one out of control web application can take down the whole instance If the libraries are well behaved, it is possible to update/reload individual web applications. As the new memory leak detection features are showing, a fair number of libs and applications are not well behaved. Personally, I think those constraints are too much for every web app so I would probably use a mixture of multiple Tomcat instances, self-container web apps and webapps that shared libraries but with a preference for self-contained web apps over shared libraries. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IS that a good idea moving all the common libs?
On 22 déc. 2010, at 12:49, Mark Thomas wrote: It is do-able if you are prepared to accept the associated constraints: - all web apps must use the exact same version of every shared library - updating the shared libraries requires a Tomcat restart - all of the shared web apps must be well behaved in a multiple class-loader environment Maybe a bit off topic, but as far as I understood, OSGI based servers (e.g. Virgo) support this type of scenario. With multiple versions of shared libraries and the possibility to deploy newer versions. Of course every piece of code must be well behaved, osgi-compliant, etc... - one out of control web application can take down the whole instance Definitely a weakness of java... PHP and other scripting platforms do not suffer from this since each process is isolated (more or less). Does somebody know how it works on .NET side ? Does it suffer from the same weakness ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IS that a good idea moving all the common libs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sylvain, On 12/22/2010 12:54 PM, Sylvain Laurent wrote: On 22 déc. 2010, at 12:49, Mark Thomas wrote: It is do-able if you are prepared to accept the associated constraints: - all web apps must use the exact same version of every shared library - updating the shared libraries requires a Tomcat restart - all of the shared web apps must be well behaved in a multiple class-loader environment Maybe a bit off topic, but as far as I understood, OSGI based servers (e.g. Virgo) support this type of scenario. With multiple versions of shared libraries and the possibility to deploy newer versions. Of course every piece of code must be well behaved, osgi-compliant, etc... I think that means they aren't shared if they can be different. - one out of control web application can take down the whole instance Definitely a weakness of java... PHP and other scripting platforms do not suffer from this since each process is isolated (more or less). This is more of a feature of the web server than the PHP interpreter: Apache httpd could easily be run under a configuration where a crashed PHP script could interfere with the operation of the server as a whole. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0SXcYACgkQ9CaO5/Lv0PBGBwCfZOHGJR/I28LFn0fQEPpGK9a1 pIoAn05qIo7HY3JCKlGNWae7694Frkrm =jyCd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: IS that a good idea moving all the common libs?
-Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Monday, December 20, 2010 1:08 PM To: Tomcat Users List Subject: Re: IS that a good idea moving all the common libs? On Dec 20, 2010, at 12:16, Luca Gervasi tom...@ashetic.net wrote: I'm trying to lower the permgen needed by a large amount of webapps moving all the commonly used libs to the tomcat common libs. That's a really, really bad idea. You would be intertwining all your webapps, potentially introducing object leaks across webapps, and creating insurmountable versioning issues. You'd also require a complete Tomcat restart to update any single webapp. I'm really not seeing that. Anyhow, would the suggestion change if you were running 300+ web applications? Webapps are intended to be independent; don't make your life miserable by tying them all together. If you need more PermGen space, configure it. If you've got memory leaks, fix them. - Chuck - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org George Sexton MH Software, Inc. 303 438-9585 www.mhsoftware.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IS that a good idea moving all the common libs?
On Dec 21, 2010, at 18:50, George Sexton geor...@mhsoftware.commailto:geor...@mhsoftware.com wrote: Anyhow, would the suggestion change if you were running 300+ web applications? The more webapps, the more important it is to keep them independent - so the suggestion would become more like an imperative. - Chuck
Re: IS that a good idea moving all the common libs?
On Dec 20, 2010, at 12:16, Luca Gervasi tom...@ashetic.net wrote: I'm trying to lower the permgen needed by a large amount of webapps moving all the commonly used libs to the tomcat common libs. That's a really, really bad idea. You would be intertwining all your webapps, potentially introducing object leaks across webapps, and creating insurmountable versioning issues. You'd also require a complete Tomcat restart to update any single webapp. Webapps are intended to be independent; don't make your life miserable by tying them all together. If you need more PermGen space, configure it. If you've got memory leaks, fix them. - Chuck - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IS that a good idea moving all the common libs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luca, On 12/20/2010 12:15 PM, Luca Gervasi wrote: I'm trying to lower the permgen needed by a large amount of webapps moving all the commonly used libs to the tomcat common libs. +1 to everything Chuck said. My questions is: how good is that idea? How many classes are we talking about? java.lang.Class objects aren't really that heavy. - -chrids -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0PumEACgkQ9CaO5/Lv0PAYKACeOOGbkG/HpSPQeHPID3b0ZYcD 1aAAoKntTbBN/zBdloPtl/8Ua35HA/HN =jRn6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IS that a good idea moving all the common libs?
Luca Gervasi schrieb am 20.12.2010 um 18:15 (+0100): I'm trying to lower the permgen needed by a large amount of webapps moving all the commonly used libs to the tomcat common libs. My questions is: how good is that idea? I read that each *same* lib in WEB-INF/lib is handled as unique, thus requiring additional permgen space. http://wiki.apache.org/commons/Logging/UndeployMemoryLeak Keep component libs in components Servlet and J2EE containers have a clear purpose: to provide a set of services to *independent* and *isolated* components. That set of services is defined by the servlet and j2ee specifications. These specifications also define a mechanism for components to provide any libraries they depend on -- WEB-INF/lib. It is therefore a complete mystery to me why people seem so keen to push libraries up out of the components where they belong and into the container's library directories. It's like pushing user code into the operating system kernel. Just don't do it. I think the fact that many developers are keen to push libraries up out of the components where they belong is due to conceptions stemming from other environments, or probably even from their deeply entrenched desire to remove redundancy from systems, like avoiding to duplicate code, or striving to normalize tables. I remember those were my motivations before I had accepted that a Java application server has been designed to work differently than I had taken for granted. -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
