Re: reducing tomcat jasper memory footprint
There are a lot of issues that show up here. 1) Using the JSP means that the entire article text (among other things) is being cached into RAM. 2) Some of the pages are popular enough that they are getting moved into the permanent area of memory, and thus avoiding the routine, cheap GCs. 3) The question whether Tomcat is somehow holding on to the JSP references to prevent them from being GC'd at all (I don't think this is the case, but you never know). As for solutions, there are several, none of which are particularly elegant I don't think. First, of course, Buy more RAM, also pronounced Let's make our Full GC's take even LONGER!. Another is to simply reboot Tomcat during a quiet time. At least this way, the down time is predictable rather than having it Crash at an unscheduled time. If the restart time is fast enough, and the site quiet enough, this may effectively solve the issue. You mentioned that the system is running several days reliably now, so, perhaps a nightly restart is not a horrible concession. Another is to mirror the site behind some kind of load balancer so that restarting the site does not actually affect users, and then go to solution one. Oh boy, more hardware to configure. You can rengineer the site. If your JSPs are reasonably regular to the point where you can write fairly simple filters to extract the actual content without resorting to crafting a JSP parser, then that is a good first step. So, going on the crass assumption that getting the article text out of your generated JSPs is not an onerous task, then the next step, to me, would be to stick a servlet Filter in front of every request. This Magic Filter (a notable anti-pattern, but...) is configured so that you will not have to actually update and rewrite all of the zillion URLs scattered throughout the site. So, www.yoursite.com/area/document.jsp in the old site is the same in the new site. The Magic Filter determines if the JSP file is a real jsp (no doubt you have some JSPs that do something other than dump static articles), versus one of your generated documents. If it is one of your generated documents, then the Magic Filter rips it apart, caches it perhaps (the ripped text), and then serves it up in a new shiny generic way as should have been done originally. If not, you let the Filter drop through and pass on so the container can handle the JSP requiest and go its merry way. Ideally, this can be done with very little change to the site, and certainly no change to the production CMS, it's ignorant of the change. Your web.xml simply has a new Filter element, and voila! I am not suggesting that this is easy or painless, but if your generated JSPs are able to be easily torn apart, then I think it's viable and practical. Perhaps your CMS JSP template can be recoded to add some comments (like !-- ARTICLE START TEXT-- This is my article !-- ARTICLE END TEXT --) that makes it easy to find articles. Perhaps you can then REGENERATE all of your older content to use the new template. You'd like to think that your CMS will allow this (kind of the whole point of a CMS at some level, isn't it?). Or, if you can not regenerate your older content, have the Magic Filter detect old vs. new and simply execute the old ones (as noted above), and filter the new ones. If your site is mostly newer content, then the old stuff will drift away and be less of a problem over time. Once up and running, your Magic Filter can cache and keep track of the status of various JSPs it encounters so as not to have to rework them each time. I would vote for the restart nightly technique and look into ways of tweaking the CMS system to spit out something you can use, but that's me. The other problem with this technique is that it is doing processing at run time which could best be done statically. For example, the fact that your CMS is generating JSPs, perhaps you can place a step in the production step that performs the parsing for you, that way it is done at production time versus request time. It depends on how easily you can modify your work flow from the CMS into the site proper. Regards, Will Hartung ([EMAIL PROTECTED]) - Original Message - From: Luc Foisy [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, December 31, 2002 7:44 AM Subject: RE: reducing tomcat jasper memory footprint Since your jsp's are generated, they should all have the same formatting. Write some code to rewrite your own non jsp pages that you can then later insert into a single jsp. Sure its some work, but in the long run it will save you some aggravation. If tomcat can rewrite your jsp on the fly, so can you. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: reducing tomcat jasper memory footprint
Thanks for your Feedback! I will look into your suggested approch using filters. answers inline - Original Message - From: Will Hartung [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 11:27 PM Subject: Re: reducing tomcat jasper memory footprint There are a lot of issues that show up here. 1) Using the JSP means that the entire article text (among other things) is being cached into RAM. 2) Some of the pages are popular enough that they are getting moved into the permanent area of memory, and thus avoiding the routine, cheap GCs. 3) The question whether Tomcat is somehow holding on to the JSP references to prevent them from being GC'd at all (I don't think this is the case, but you never know). As of 4.0.4 tomcat keeps a reference to every generated servlet, so increasing the memory size only delays the OutOfMemoryError. As for solutions, there are several, none of which are particularly elegant I don't think. First, of course, Buy more RAM, also pronounced Let's make our Full GC's take even LONGER!. Another is to simply reboot Tomcat during a quiet time. At least this way, the down time is predictable rather than having it Crash at an unscheduled time. If the restart time is fast enough, and the site quiet enough, this may effectively solve the issue. You mentioned that the system is running several days reliably now, so, perhaps a nightly restart is not a horrible concession. Another is to mirror the site behind some kind of load balancer so that restarting the site does not actually affect users, and then go to solution one. Oh boy, more hardware to configure. In fact we are using loadbalancing using apache 1.3.26, mod_jk, and 3 tomcat instances. Every night one tomcat get's restarted. Basically we use the lb-options local_worker local_worker_only to disable a tomcat instance at midnight and restart it at 4:00. Otherwise the big problem with restarting tomcat is loss of our session-data. Saving and restoring the data in the SESSIONS.ser file doesn't help, since the loadbalancer routes the web clients to another tomcat instance where they get another sessionId. I once experimented with tomcat clustering using the source from http://www.filip.net/tomcat/ but this was some months ago and didn't work very well at this early stage . You can rengineer the site. If your JSPs are reasonably regular to the point where you can write fairly simple filters to extract the actual content without resorting to crafting a JSP parser, then that is a good first step. So, going on the crass assumption that getting the article text out of your generated JSPs is not an onerous task, then the next step, to me, would be to stick a servlet Filter in front of every request. This Magic Filter (a notable anti-pattern, but...) is configured so that you will not have to actually update and rewrite all of the zillion URLs scattered throughout the site. So, www.yoursite.com/area/document.jsp in the old site is the same in the new site. The Magic Filter determines if the JSP file is a real jsp (no doubt you have some JSPs that do something other than dump static articles), versus one of your generated documents. If it is one of your generated documents, then the Magic Filter rips it apart, caches it perhaps (the ripped text), and then serves it up in a new shiny generic way as should have been done originally. If not, you let the Filter drop through and pass on so the container can handle the JSP requiest and go its merry way. Ideally, this can be done with very little change to the site, and certainly no change to the production CMS, it's ignorant of the change. Your web.xml simply has a new Filter element, and voila! I am not suggesting that this is easy or painless, but if your generated JSPs are able to be easily torn apart, then I think it's viable and practical. Perhaps your CMS JSP template can be recoded to add some comments (like !-- ARTICLE START TEXT-- This is my article !-- ARTICLE END TEXT --) that makes it easy to find articles. Perhaps you can then REGENERATE all of your older content to use the new template. You'd like to think that your CMS will allow this (kind of the whole point of a CMS at some level, isn't it?). Or, if you can not regenerate your older content, have the Magic Filter detect old vs. new and simply execute the old ones (as noted above), and filter the new ones. If your site is mostly newer content, then the old stuff will drift away and be less of a problem over time. Once up and running, your Magic Filter can cache and keep track of the status of various JSPs it encounters so as not to have to rework them each time. I would vote for the restart nightly technique and look into ways of tweaking the CMS system to spit out something you can use, but that's me. The other problem with this technique is that it is doing processing at run time which could
Re: reducing tomcat jasper memory footprint
From: Julian Löffelhardt [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 5:38 PM Subject: Re: reducing tomcat jasper memory footprint Thanks for your Feedback! Sure! I will look into your suggested approch using filters. answers inline with comments... As of 4.0.4 tomcat keeps a reference to every generated servlet, so increasing the memory size only delays the OutOfMemoryError. Yeah, I saw that blurb. That's unfortunate, because in truth this is the crux of your problem. It is not so bad that a popular JSP gets cached into RAM, that is a good thing. That is what RAM is for. However, in this case, even the rarest and most unpopular of your JSPs are getting cached permanently. Owie. In fact we are using loadbalancing using apache 1.3.26, mod_jk, and 3 tomcat instances. Every night one tomcat get's restarted. Basically we use the lb-options local_worker local_worker_only to disable a tomcat instance at midnight and restart it at 4:00. Otherwise the big problem with restarting tomcat is loss of our session-data. Saving and restoring the data in the SESSIONS.ser file doesn't help, since the loadbalancer routes the web clients to another tomcat instance where they get another sessionId. Are you able to isolate a particular instance/server so that current users can continue with the site, while no new users go there? If that is possible with your configuration, then you do not really have a session problem as they should be invalid by the user logging out/going away/timing out. I thought about converting the documents into velocity templates or something like that using a postprocessor but decided against it: 1) Would be quite comlicated, due to the complex structure of the pages. 2) First I would need to proove that my suggested different design would work better. To be fair, replacing JSP with Velocity, particularly a JSP generated by another program (i.e. not written directly by a CBL (Carbon Based Lifeform)) implies that the execution of the compiled JSP page is slower than the intpretation of the Velocity template (modulo the fact that Tomcat does not GC JSPs, but that is a detail for this discussion). I do not have any data either way as to which is faster. We get about 400.000 PageImpressions/day and under high load many concepts/designs/applications just dont't deliver For example, we performed extensive stress-tests on our application but the tests didn't reveal the problems with too many different jsp-Files since our tests where mainly focused on performance issues and we only used about 100 pages for testing. In truth, there is not anything really wrong with your overall design. Most complaints about JSP focus on maintainability of the JSP files, and the intermixing of code and HTML etc. Velocity implicity suffers from that same issue, though perhaps its syntax and model may be better. But these are not direct issues with your system, as your JSPs are derivative products of your CMS system. In my opinion, your use of JSPs here is no different from using something akin to the Olde Tyme Server Side Includes. The facts seem to be that save for the memory issue, you system is behaving fine, and, as you noted, your JSP solution appears to scale better. And well it should with all of your pages cached in RAM :-). So, I would look at the other message in the list that mentioned the Jasper class loaders hash table and perhaps changing that to support an LRU queue rather than a hash table. I know it is a complicated and not necessarily well understood area for most developers, but it IS the source of your problem. I think that if you spend a little bit of time in that section of code, you have a better chance for success in a shorter amount of time. Also, once you load test the heck out of if and stress it as best as you can, it is probably much safer as from a logical or even implementation point of view, your application does not change at all. Ideally, it can simply be a change from a HashTable (or HashMap, whatever they are using) to an LRUMap (of somekind, this is left as an exercise for the reader :-) -- maybe you can safely use WeakReferences here), with all of the Real Hard Work (tm) done by the surrounding code. Granted, this means you must go through the nightmare of actually BUILDING Tomcat (not for the meek). The code in place already deals with loading class files, checking the map for loaded classes, synchronization issues, etc. So what is the difference between checking a HashMap for a class and loading it if it does not exist (in this case the first time the page is loaded), and seeing that the class is not there because it happened to drop off the end of the queue? It should not matter why the class is not in the map, but simply that it is not there. For normal operations and classes, this is less of an issue, but your classes are really content so they suck up an extraordinary amount of memory. Also, for normal classes this can
Re: reducing tomcat jasper memory footprint
On Tue, 2002-12-31 at 01:55, Julian Löffelhardt wrote: Hi, My problem isin't javac memory leakes. Due to the apache/tomcat documentation I was aware of this an setup jikes as my jsp compiler. I'm also using JDK 1.4.1 so the javac issues should be solved, nonetheless. The main problem is as follows: 1. Every article every page in general is a jsp page 2. All the pages are generated by a legacy CMS-System (imperia) and I can't change the structure of it's works. 3. Every jsp page, once loaded, consumes memory, since the class remains loaded. 4. We have 1000s of pages , every day some 200-300 new, so memory use increases. Conclusion: The way we use jsp's for a cms is faulty. But I can't do anything about this. Increasing permSize of the JVM helps a lot. Maybe it would be a good idea to include some hints about -XX:MaxPermSize and XX:PermSize into the documentation because it really helps lessen the problems. But: Is there any generic way to get a stable tomcat with huge number of jsp's ? there was a thread on the developer list talking about thread pools and expiration of web apps. I don't know about the state of this, but your problem would probably be solved by this. If you could manage to make groups of webapps, let's say per day, knowing that the servlets of a certain day never get used on the following day, and if this thread webapp-cleaner was implemented, your old webapps would get removed. You probably would be able to group your jsps differently depending on your use. Have a look at the thread named Re: [PATCH] Re: ThreadPool It's not yet there, but if it gets implemented, you can probably wait using daily/nighly restarts of tomcat. I don't see anything else if you don't have control of the content that gets generated. j. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: reducing tomcat jasper memory footprint
Since your jsp's are generated, they should all have the same formatting. Write some code to rewrite your own non jsp pages that you can then later insert into a single jsp. Sure its some work, but in the long run it will save you some aggravation. If tomcat can rewrite your jsp on the fly, so can you. -Original Message- From: Julian Löffelhardt [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 7:55 PM To: Tomcat Users List Subject: Re: reducing tomcat jasper memory footprint Hi, My problem isin't javac memory leakes. Due to the apache/tomcat documentation I was aware of this an setup jikes as my jsp compiler. I'm also using JDK 1.4.1 so the javac issues should be solved, nonetheless. The main problem is as follows: 1. Every article every page in general is a jsp page 2. All the pages are generated by a legacy CMS-System (imperia) and I can't change the structure of it's works. 3. Every jsp page, once loaded, consumes memory, since the class remains loaded. 4. We have 1000s of pages , every day some 200-300 new, so memory use increases. Conclusion: The way we use jsp's for a cms is faulty. But I can't do anything about this. Increasing permSize of the JVM helps a lot. Maybe it would be a good idea to include some hints about -XX:MaxPermSize and XX:PermSize into the documentation because it really helps lessen the problems. But: Is there any generic way to get a stable tomcat with huge number of jsp's ? Thanks for all ya feedback llap + happy new year... julian - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, December 30, 2002 9:40 PM Subject: Re: reducing tomcat jasper memory footprint Paul Yunusov wrote: On Monday 30 December 2002 02:37 pm, Julian Löffelhardt wrote: Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? llap, julian JAVAC leaks memory every time a JSP class is compiled. The more JSPs are compiled or the more often JSP classes are compiled, the more memory is leaked. You exacerbate this problem by generating a JSP per article often. IMHO, generating a JSP per article is misusing the technology. JSP is a templating solution whereas one JSP describes a layout of any number of end documents. I suggest you change your software to generate an HTML file per artcile rather than a JSP. Maybe it's abusing the technology, but it really should work fine. Workarounds for the problem include using jikes, or using javac out of process (I don't quite remember how it is configured; since Jasper 2 uses Ant javac task to compile, it should be in the Ant docs on the javac task). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: reducing tomcat jasper memory footprint
Julian I would consider writing some sort of pre-processing program that will convert the documents form individual jsps to one generic jsp that processes the body of the document. Either the raw jsp could be processed or the html generated from it captured and processed. If they are machine generated jsps, they might not be too hard to extract out the variable portion. I've been looking at Geary's templates (link below). It has some nice capabilities. http://developer.java.sun.com/developer/technicalArticles/javaserverpages/jsp_templates/ Chuck -Original Message- From: Julian Löffelhardt [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 11:37 AM To: Tomcat Users List Subject: reducing tomcat jasper memory footprint Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? llap, julian -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: reducing tomcat jasper memory footprint
I don't have an answer to your exact question, but given the numbers you cite I would try to come up with an alternative design. Perhaps you can create one JSP page that uses dynamic includes to incorporate the text of the article? Just a thought. -Original Message- From: Julian Löffelhardt [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 2:37 PM To: Tomcat Users List Subject: reducing tomcat jasper memory footprint Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? llap, julian -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: reducing tomcat jasper memory footprint
Could this be also related to the leaks of the java compiler? Did you try to precompile the JSPs before deploying them (using JSPC) ? Perhaps does that help? Jerome On Mon, 2002-12-30 at 20:37, Julian Löffelhardt wrote: Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? llap, julian -- Jerome Lacoste (Frisurf) [EMAIL PROTECTED] CoffeeBreaks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: reducing tomcat jasper memory footprint
If I'd only known about this problem a few months earlier Sad truth is that I can't change this (too) jsp-centric design. llap, julian - Original Message - From: Wagoner, Mark [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Monday, December 30, 2002 8:48 PM Subject: RE: reducing tomcat jasper memory footprint I don't have an answer to your exact question, but given the numbers you cite I would try to come up with an alternative design. Perhaps you can create one JSP page that uses dynamic includes to incorporate the text of the article? Just a thought. -Original Message- From: Julian Löffelhardt [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 2:37 PM To: Tomcat Users List Subject: reducing tomcat jasper memory footprint Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? llap, julian -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: reducing tomcat jasper memory footprint
Hi, I use jikes to compile the pages. Since raising the JVM permanent segment size delays the error the problem seems to come from the sheer size of the loaded class files. So theorectically it shouldn't matter wheter the pages are precompiled or not. Anyway I 'm about to set up a test specifically for this, to measure how many pages can be loaded before an error occurs. llap, julian - Original Message - From: Jerome Lacoste (Frisurf) [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, December 30, 2002 8:51 PM Subject: Re: reducing tomcat jasper memory footprint Could this be also related to the leaks of the java compiler? Did you try to precompile the JSPs before deploying them (using JSPC) ? Perhaps does that help? Jerome On Mon, 2002-12-30 at 20:37, Julian Löffelhardt wrote: Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? llap, julian -- Jerome Lacoste (Frisurf) [EMAIL PROTECTED] CoffeeBreaks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: reducing tomcat jasper memory footprint
On Monday 30 December 2002 02:37 pm, Julian Löffelhardt wrote: Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? llap, julian JAVAC leaks memory every time a JSP class is compiled. The more JSPs are compiled or the more often JSP classes are compiled, the more memory is leaked. You exacerbate this problem by generating a JSP per article often. IMHO, generating a JSP per article is misusing the technology. JSP is a templating solution whereas one JSP describes a layout of any number of end documents. I suggest you change your software to generate an HTML file per artcile rather than a JSP. Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: reducing tomcat jasper memory footprint
Julian, I would have to agree that creating a JSP per article is a bit much. How did you or your group arrive at using this solution? The other possible solutions I have seen would include a single JSP that pulls the data from a database or creating XML files that are formatted with XSLT instead of JSP's Is the system doing some processing that requires one page or article or requires JSP capabilities that aren't found in XML/XSLT files? Sincerely, Pantek Incorporated Justin L. Spies URI: http://www.pantek.com Ph 440.519.1802 Fax 440.248.5274 Cell 440.336.3317 -Original Message- From: Paul Yunusov [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 3:31 PM To: Tomcat Users List Subject: Re: reducing tomcat jasper memory footprint On Monday 30 December 2002 02:37 pm, Julian Löffelhardt wrote: Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? llap, julian JAVAC leaks memory every time a JSP class is compiled. The more JSPs are compiled or the more often JSP classes are compiled, the more memory is leaked. You exacerbate this problem by generating a JSP per article often. IMHO, generating a JSP per article is misusing the technology. JSP is a templating solution whereas one JSP describes a layout of any number of end documents. I suggest you change your software to generate an HTML file per artcile rather than a JSP. Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: reducing tomcat jasper memory footprint
Paul Yunusov wrote: On Monday 30 December 2002 02:37 pm, Julian Löffelhardt wrote: Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? llap, julian JAVAC leaks memory every time a JSP class is compiled. The more JSPs are compiled or the more often JSP classes are compiled, the more memory is leaked. You exacerbate this problem by generating a JSP per article often. IMHO, generating a JSP per article is misusing the technology. JSP is a templating solution whereas one JSP describes a layout of any number of end documents. I suggest you change your software to generate an HTML file per artcile rather than a JSP. Maybe it's abusing the technology, but it really should work fine. Workarounds for the problem include using jikes, or using javac out of process (I don't quite remember how it is configured; since Jasper 2 uses Ant javac task to compile, it should be in the Ant docs on the javac task). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: reducing tomcat jasper memory footprint
On Mon, 30 Dec 2002, Julian Löffelhardt wrote: Date: Mon, 30 Dec 2002 20:37:10 +0100 From: Julian Löffelhardt [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: reducing tomcat jasper memory footprint Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? There is not. But I can't help thinking that a better strategy might be to use a single JSP page (or perhaps one per different layout of the published articles) that build the content dynamically, instead of using a separate JSP page per article. Or else, maybe you could generate static HTML files instead of JSP that then has to be compiled and executed every time the article is read. llap, julian Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: reducing tomcat jasper memory footprint
One question with regard to using jsp files as included content: I'm having a requirement to include files with more or less simple html content. That's in order to make editing easier for other users. I currently keep some html content in files which I reference by a database id. So a view jsp file is taking some content directly from the database and some by including a file with a name like content[ID].jsp But because I need session tracking and the possibility exists that i have url links in the included content from time to time, I decided to have jsp include files instead of html. Otherwise I couldn't use encodeURL to add session ids for browsers that disallow cookies. Actually it's unlikely that I'd use more Java than this encodeURL() so I would consider using some other technique to do it, if I knew another way. The only thing I could think of would be a filter servlet to encode the urls of those include html files on-the-fly. Any better or easier ideas? Michael -Original Message- From: Justin L. Spies [mailto:[EMAIL PROTECTED]] Sent: Montag, 30. Dezember 2002 21:34 To: 'Tomcat Users List'; [EMAIL PROTECTED] Subject: RE: reducing tomcat jasper memory footprint Julian, I would have to agree that creating a JSP per article is a bit much. How did you or your group arrive at using this solution? The other possible solutions I have seen would include a single JSP that pulls the data from a database or creating XML files that are formatted with XSLT instead of JSP's Is the system doing some processing that requires one page or article or requires JSP -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: reducing tomcat jasper memory footprint
the a bad thing is that the jasper generated code creates for each request all string object new. So hundred unneeded String objects consuming a lot off memory. And so big pages with many poor texts without codeneeds a big amount of memory. Torsten Fohrer On Monday 30 December 2002 20:37, you wrote: Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? llap, julian -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: reducing tomcat jasper memory footprint
Could you explain this further? What exactly is the many poor 'texts'? Thanks Torsten. -Dan -Original Message- From: Torsten Fohrer [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 4:39 PM To: Tomcat Users List Subject: Re: reducing tomcat jasper memory footprint the a bad thing is that the jasper generated code creates for each request all string object new. So hundred unneeded String objects consuming a lot off memory. And so big pages with many poor texts without codeneeds a big amount of memory. Torsten Fohrer On Monday 30 December 2002 20:37, you wrote: Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? llap, julian -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: reducing tomcat jasper memory footprint
Hi, My problem isin't javac memory leakes. Due to the apache/tomcat documentation I was aware of this an setup jikes as my jsp compiler. I'm also using JDK 1.4.1 so the javac issues should be solved, nonetheless. The main problem is as follows: 1. Every article every page in general is a jsp page 2. All the pages are generated by a legacy CMS-System (imperia) and I can't change the structure of it's works. 3. Every jsp page, once loaded, consumes memory, since the class remains loaded. 4. We have 1000s of pages , every day some 200-300 new, so memory use increases. Conclusion: The way we use jsp's for a cms is faulty. But I can't do anything about this. Increasing permSize of the JVM helps a lot. Maybe it would be a good idea to include some hints about -XX:MaxPermSize and XX:PermSize into the documentation because it really helps lessen the problems. But: Is there any generic way to get a stable tomcat with huge number of jsp's ? Thanks for all ya feedback llap + happy new year... julian - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, December 30, 2002 9:40 PM Subject: Re: reducing tomcat jasper memory footprint Paul Yunusov wrote: On Monday 30 December 2002 02:37 pm, Julian Löffelhardt wrote: Hi, I'm using Apache 1.3.26 and 3 tomcat 4.0.4 instances with AJP13 loadbalancing . Our application is a CMS where all the published articles are generated offline as JSP-Files, one jsp per article. We had hige problems with the memory footprint. Due to the fact that every jsp is generated as a class and there are about 200 new artices per day the permanent segment of the JVM heap gets filled with all the classes, and I get an OutOfMemoryError. My workaround for now is setting -XX:PermSize and --XX:MapPermSize to higher values, but this just delays application hang-up. With 64 megs of permSize our Server had an approx. uptime of 1 day now it's about 3-4 days. Is there any way to unload jsp-Files (unload the class) ? llap, julian JAVAC leaks memory every time a JSP class is compiled. The more JSPs are compiled or the more often JSP classes are compiled, the more memory is leaked. You exacerbate this problem by generating a JSP per article often. IMHO, generating a JSP per article is misusing the technology. JSP is a templating solution whereas one JSP describes a layout of any number of end documents. I suggest you change your software to generate an HTML file per artcile rather than a JSP. Maybe it's abusing the technology, but it really should work fine. Workarounds for the problem include using jikes, or using javac out of process (I don't quite remember how it is configured; since Jasper 2 uses Ant javac task to compile, it should be in the Ant docs on the javac task). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
