Re: Memory Settings On Tomcat
Endre Stølsvik wrote: Why not? I don't think this is correct. See, if the class isn't referenced anymore, by not having any referenced objects of that class (by any reference), nor having the class object referenced, on the stack of any of the JVM's created Threads, then the static fields of that class isn't referenced either, and thus both will be gc'ed, and then the classloader will be gc'ed.. More on this here: http://java.sun.com/docs/books/jls/second_edition/html/execution.doc.html#74294 IMHO there is no problem in classloaders being thrown away. BTW NetBeans module system successfully unloads (discards) disabled modules. Don't know why tomcat should not do the same ... (But you might have to deal with http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646668 and maybe other subtle problems). David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.0.16 running out of resources
Hi, also consider upgrading to 5.0.18 - there was a memory leak fixed in tomcat. You can search the archive of this conference to find more info. Best, David Jake Alley wrote: Hi, I'm running Tomcat 5.0.16 and I'm getting the following error peiiodically: The system is out of resources. Consult the following stack trace for details. java.lang.OutOfMemoryError It happens when certain jsp forms are compiled. Is there a way to increase the amount of system resources? Sometimes the server just stops working and leaves no log traces as well. Could these be related? This is with code that worked fine in version 4. Thanks. _ Optimize your Internet experience to the max with the new MSN Premium Internet Software. http://click.atdmt.com/AVE/go/onm00200359ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: out of memory problem. Help!
If you use tomcat 5.0.x upgrade to 5.0.18. If you use 4.1.x downgrade to 4.1.27. There is a significant memory leak in tomcat in 5.0.16, 4.1.28(29). Hope this helps, David Christian Witucki wrote: We fixed our session timeout to 15 minutes for 100 users and Tomcat hasn't crashed for 36 hours. Does anyone know how we can adjust for the possibilities of 1000's of users??? Christian Witucki Network Analyst 375 Essjay Road Williamsville, NY 14221 716-631-3001 x3812 CONFIDENTIALITY NOTICE. This e-mail and attachments, if any, may contain confidential information which is privileged and protected from disclosure by Federal and State confidentiality laws, rules or regulations. This e-mail and attachments, if any, are intended for the designated addressee only . If you are not the designated addressee, you are hereby notified that any disclosure, copying, or distribution of this e-mail and its attachments, if any, may be unlawful and may subject you to legal consequences. If you have received this e-mail and attachments in error, please contact Independent Health immediately at (716) 631-3001 and delete the e-mail and its attachments from your computer. Thank you for your attention. [EMAIL PROTECTED] 01/19/04 01:20AM Check session-timeout in web.xml. -1 is never timeout session-timeout-1/session-timeout -Original Message- From: Christophe Andreoli [mailto:[EMAIL PROTECTED] Sent: Friday, January 16, 2004 9:19 PM To: Tomcat Users List Subject: Re: out of memory problem. Help! Shapira, Yoav wrote: Howdy, root cause java.lang.OutOfMemoryError It happens When the corresponding request returns more than 2-3 rows from the database, not every time Perhaps you should allocate your JVM more memory, by using the Java -Xmx parameter. I did it and I gave 512 Mb. It works better but why are the 2000 objects are not garbaged after each request ? Alternatively, consider a system design that retrieves a smaller, fixed number of rows instead of 2-3 and lets the user scroll, say 100 rows at a time. Yoav Shapira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: out of memory problem. Help!
I am not on the developer team. But spent quite a lot of hours (days) latelly with figuring out why my copy of tomcat (4.1.29) leaks memory. The information bellow is based on the info from the dev mailing list + a thread on this mailing list with subject Tomcat Tuning Memory leak from last couple of days (weeks). I am still testing 4.1.27 and all seems fine so far. Re 5.0.18: thats a revision where the fix was commited - please check the dev mailing list with subject Found it - WAS: Memory leak and RE: [5.0.18] Build available. Hope this helps, David Allistair Crossley wrote: This is very interesting to hear. I can believe it too...we lose between 400K and 5MB per request and Tomcat 5.0.16 bombs out at 155. We have invested in JProfiler now to see why but your comment is curious. Are you on the development team? When will 5.0.18 become stable...does not seem to be a binary download yet Cheers ADC -Original Message- From: David Strupl [mailto:[EMAIL PROTECTED] Sent: 19 January 2004 17:00 To: [EMAIL PROTECTED] Subject: Re: out of memory problem. Help! If you use tomcat 5.0.x upgrade to 5.0.18. If you use 4.1.x downgrade to 4.1.27. There is a significant memory leak in tomcat in 5.0.16, 4.1.28(29). Hope this helps, David Christian Witucki wrote: We fixed our session timeout to 15 minutes for 100 users and Tomcat hasn't crashed for 36 hours. Does anyone know how we can adjust for the possibilities of 1000's of users??? Christian Witucki Network Analyst 375 Essjay Road Williamsville, NY 14221 716-631-3001 x3812 CONFIDENTIALITY NOTICE. This e-mail and attachments, if any, may contain confidential information which is privileged and protected from disclosure by Federal and State confidentiality laws, rules or regulations. This e-mail and attachments, if any, are intended for the designated addressee only . If you are not the designated addressee, you are hereby notified that any disclosure, copying, or distribution of this e-mail and its attachments, if any, may be unlawful and may subject you to legal consequences. If you have received this e-mail and attachments in error, please contact Independent Health immediately at (716) 631-3001 and delete the e-mail and its attachments from your computer. Thank you for your attention. [EMAIL PROTECTED] 01/19/04 01:20AM Check session-timeout in web.xml. -1 is never timeout session-timeout-1/session-timeout -Original Message- From: Christophe Andreoli [mailto:[EMAIL PROTECTED] Sent: Friday, January 16, 2004 9:19 PM To: Tomcat Users List Subject: Re: out of memory problem. Help! Shapira, Yoav wrote: Howdy, root cause java.lang.OutOfMemoryError It happens When the corresponding request returns more than 2-3 rows from the database, not every time Perhaps you should allocate your JVM more memory, by using the Java -Xmx parameter. I did it and I gave 512 Mb. It works better but why are the 2000 objects are not garbaged after each request ? Alternatively, consider a system design that retrieves a smaller, fixed number of rows instead of 2-3 and lets the user scroll, say 100 rows at a time. Yoav Shapira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Developers of QuickAddress Software a href=http://www.qas.com;www.qas.com/a Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: out of memory problem. Help!
Remy Maucherat wrote: This is not true: there's indeed a memory leak with 5.0.16, but it would occur only with specific traffic patterns. It will not bring a server down in just a few requests. Indeed. The thread pool has to grow and shrink for this to happen. Unfortunatelly quite common e.g. day and night traffic. D. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: out of memory problem. Help!
This did not work for me in 4.1.29 since the only way to do this is to set minProcessors==maxProcessors but that did not have any effect in 4.1.29. I am not sure whether I could use xxxThreads there but downgrading to 4.1.27 did help. For those using 5.0.16 this can help - Filip thanks for finding out. Best, David Filip Hanik wrote: set maxSpareThreads=minSpareThreads=maxThreads will cause the system to never shrink the pool Filip -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of David Strupl Sent: Monday, January 19, 2004 9:58 AM To: [EMAIL PROTECTED] Subject: Re: out of memory problem. Help! Remy Maucherat wrote: This is not true: there's indeed a memory leak with 5.0.16, but it would occur only with specific traffic patterns. It will not bring a server down in just a few requests. Indeed. The thread pool has to grow and shrink for this to happen. Unfortunatelly quite common e.g. day and night traffic. D. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Tuning Memory leak
Hi (yes that's me again), I have more details for those that would be willing to help. I have started to use IBM's JDK that has the nice memory dump feature set up so that whenever OutOfMemory occurs the heap is dumped. So my heap is here http://hry.atlas.cz/zaloha/heapdump.20040114.160700.8886.txt.gz Probably no need to download the 12MB - I have tried to process it and interesting result is this: I have used the k function of HeapRoots205 (here is its description): This executes by first running 'p 0x1234'. This leaves every object reachable by 0x1234 owned by it. Then any objects which are owned by 0x1234 but reachable from outside of this set are removed. This leaves 0x1234 owning exactly those objects which are only reachable thru' it. on following object: k 0x10102818 Calculating keep-alive size of 0x10102818 'org/apache/coyote/RequestGroupInfo' ... Requesting 17 mb of heapspace to process heapdump ... done. Finding pure Roots .. done. DFS from 0x10102818 . done. Total reach (inclusive) 1,245,481 objects. Total-size is 299,128,896. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Tuning Memory leak
My previous post should be longer ... here is the rest: DFS from pure Roots ...done. DFS from objects unreached from Roots ...done. Found 1,051,382 objects which are reachable from elsewhere. These will be taken from 0x10102818 and then owned by other objects ... DFS from 0x10102818 . done. Keep-alive size (inclusive) is 194,099 objects. Total-size is 154,016,544. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Tuning Memory leak
Still I don't see the whole thing - and trying to send the rest here: If I interpret it correctly the instance of org/apache/coyote/RequestGroupInfo holds 150 MB of heap memory. Also if I understand it correctly from here http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ someone just recently tried to do something with it. Am I totally paranoic when I suspect that the memory leak is in tomcat? Thanks for any hints (as usually) and best regards, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Tuning Memory leak
Shapira, Yoav wrote: You're not paranoid. There's a memory leak related to the RequestGroup/RequestGroupInfo connector code. It's been discussed during the past week on the dev mailing list, and addressed within the past couple of days. You can try the tomcat 5.0.18 build which has the fix. Yoav Shapira Thanks for the pointer. Although they talk only about 5.0.x I thing that the problem is present even in 4.1.29 - it might make sense to only downgrade to 4.1.27 because the classes in question were not there ... I will first try to set minProcessors==maxProcessors and see whether it helps even in 4.1.29. If it won't help I will think about moving to some other revision. Thanks again and best regards, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Tuning Memory leak
Hi, I have the very same problem. I have tried everything possible with no outcome (the fork atribute for the jsp compiler did not help (with this I refer to a previous discussion here)). I suspect the CoyoteConnector being at fault but have no proof yet. I plan to run profiler but doing that with users hanging on our machine it requires a bit of courage. If you manage to solve this problem somehow please let me know (on this mailing list) because there is at least one person _very_ interested in solving this problem. Even if you succeed by trying another connector I would like to hear. Good luck and best regards, David Mohit Gupta wrote: Hi All I am working on Tomcat 4.1.24 on Solatis-8, 12 CPU, 24GB RAM Machine. I am using Apache 2.0.43 and the Jdk version is 1.4.1_02. When I start my server then after 5-6 hours my server becomes very slow and then I need to restart my server. I am taking the top stats for the tomcat and have found that normally the thread remains between 100- 140 but when the system crashes it reaches to 372 and the memory gradually increases from 256 to some where around 660. The top stats are as follows PID USERNAME THR PRI NICE SIZE RES STATETIMECPU COMMAND 13082 root 115 00 653M 578M cpu/290 313:31 37.64% java 13082 root 139 70 654M 579M cpu/291 388:08 40.78% java 13082 root 143 00 654M 580M cpu/419 466:39 41.43% java 13082 root 374 10 662M 589M cpu/323 547:47 47.03% java 13082 root 374 100 662M 589M cpu/291 625:42 53.59% java Here the Thread count increases from 143 to 374 in just 10 min. Even though the no of user accessing this site has decreased. I really dont know what the problem is... I have set the Catalina Option as -Xms128M -Xmx512M but even setting the value of -XMx1024 doesn't solved my problem. The connector settings in my server.xml are as follows Connector className=org.apache.coyote.tomcat4.CoyoteConnector acceptCount=5 bufferSize=2048 connectionTimeout=2 debug=0 disableUploadTimeout=false enableLookups=false maxProcessors=350 minProcessors=5 port=8009 protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler proxyPort=0 redirectPort=8443 scheme=http secure=false tcpNoDelay=true useURIValidationHack=false Factory className=org.apache.catalina.net.DefaultServerSocketFactory/ /Connector Please tell me what is the problem with my configuration. Please help me Thanks Regards Mohit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Tuning Memory leak
Ooops. I was too fast with my previous post. My config is different form yours: Connector className=org.apache.coyote.tomcat4.CoyoteConnector address=212.47.18.50 acceptCount=100 bufferSize=2048 compression=off connectionLinger=-1 connectionTimeout=2 connectionUploadTimeout=30 debug=0 disableUploadTimeout=true enableLookups=false maxKeepAliveRequests=100 maxProcessors=250 minProcessors=25 port=80 protocolHandlerClassName=org.apache.coyote.http11.Http11Protocol proxyPort=0 redirectPort=8443 scheme=http secure=false serverSocketTimeout=0 tcpNoDelay=true tomcatAuthentication=true useURIValidationHack=false Factory className=org.apache.catalina.net.DefaultServerSocketFactory/ /Connector Also my machine is a bit smaller ;-) (with linux). But the behaviour is very similar. Best, David David Strupl wrote: Hi, I have the very same problem. I have tried everything possible with no outcome (the fork atribute for the jsp compiler did not help (with this I refer to a previous discussion here)). I suspect the CoyoteConnector being at fault but have no proof yet. I plan to run profiler but doing that with users hanging on our machine it requires a bit of courage. If you manage to solve this problem somehow please let me know (on this mailing list) because there is at least one person _very_ interested in solving this problem. Even if you succeed by trying another connector I would like to hear. Good luck and best regards, David Mohit Gupta wrote: Hi All I am working on Tomcat 4.1.24 on Solatis-8, 12 CPU, 24GB RAM Machine. I am using Apache 2.0.43 and the Jdk version is 1.4.1_02. When I start my server then after 5-6 hours my server becomes very slow and then I need to restart my server. I am taking the top stats for the tomcat and have found that normally the thread remains between 100- 140 but when the system crashes it reaches to 372 and the memory gradually increases from 256 to some where around 660. The top stats are as follows PID USERNAME THR PRI NICE SIZE RES STATETIMECPU COMMAND 13082 root 115 00 653M 578M cpu/290 313:31 37.64% java 13082 root 139 70 654M 579M cpu/291 388:08 40.78% java 13082 root 143 00 654M 580M cpu/419 466:39 41.43% java 13082 root 374 10 662M 589M cpu/323 547:47 47.03% java 13082 root 374 100 662M 589M cpu/291 625:42 53.59% java Here the Thread count increases from 143 to 374 in just 10 min. Even though the no of user accessing this site has decreased. I really dont know what the problem is... I have set the Catalina Option as -Xms128M -Xmx512M but even setting the value of -XMx1024 doesn't solved my problem. The connector settings in my server.xml are as follows Connector className=org.apache.coyote.tomcat4.CoyoteConnector acceptCount=5 bufferSize=2048 connectionTimeout=2 debug=0 disableUploadTimeout=false enableLookups=false maxProcessors=350 minProcessors=5 port=8009 protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler proxyPort=0 redirectPort=8443 scheme=http secure=false tcpNoDelay=true useURIValidationHack=false Factory className=org.apache.catalina.net.DefaultServerSocketFactory/ /Connector Please tell me what is the problem with my configuration. Please help me Thanks Regards Mohit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Tuning Memory leak
David Rees wrote: Additionally, upgrading to the latest Tomcat (4.1.27 or 5.0.16) and JDK (1.4.2_03) is a good idea as the latest versions have bug fixes and performance improvements. I doubt it is a Tomcat issue, it is more than likely an issue with your application, but the stack trace will show the cause. I have tomcat 4.1.29, JDK1.4.2. Also my app was completely ok with tomcat 3.x.x. The 100% of processor time occurs in my case only after the OOME. Before the OOME all the threads (both tomcat's and mine) are happy. Thanks for any hints, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Tuning Memory leak
Philipp Taprogge wrote: The processor usage is not too surprising. When your machine runs out of memory and there are still busy processes, most of the cpu time will go into swapping in and out those processes. Still, since most prople are perfectly happy with the tomcat build you are using, there seems to be a problem with your application code. Perhaps you could elaborate a bit further here? And, as we had that subject a few days ago, are you by chance re-using StringBuffer instances ;-) Yes - I was also not surprised with the CPU after the OOME. I will try to prepare a heap shapshot and post it here (only a link, don't worry) after I manage to get a usefull one. My application does not do anything special - it is an online gaming server with couple of JSPs and servlets. The profiling has not revealed any memory leak in my code so far. Also the code was running for several years in tomcat 3.x without any problem. After migrating to tomcat 4.x the nightmare began. Thanks for any hints, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Tuning Memory leak
Philipp Taprogge wrote: Have you changed the JRE as well or are you running the tomcat 4 instance in the same VM as the tomcat 3 before? Just to make sure your problems are not arising from changes made to the JVM in the meantime. I have upgraged the VM as well as the OS on the machine. In fact the whole machine is different now (being it dual-pentium this time). Right now I am further upgrading SUN JDK 1.4.2 to SUN 1.4.2_03 if that is going to have any impact. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Tuning Memory leak
Shapira, Yoav wrote: (BTW, to refresh my memory, is this setup where the JSP pages change hourly?) I have already changed this ;-) Also added the fork attribute to true for jsp compile. It is not caused by the app - after the app starts and first 100 or so users connect the memory jumps up to approx 130 MB. But during the next 24 hours it eats more than 300 megs. From what I have seen from the profiler so far number of my objects is fairly decent. But there are more and more approx 100k (98320 chars) buffers created somewhere. I will post more precise info later after I a. upgrade to the latest and greatest JDK 1.4.2_03 b. create some HTML output of the heap Thanks for any hints so far, best regards, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: setting opts to avoid OutOfMemory errors
David Rees wrote: David Strupl wrote: Sorry but how do I set the fork attribute of the JspServlet to true? Look at Tomcat's conf/web.xml, and you will see it. Aha. I see. I was editing only server.xml previously. This seems like an obvoius memory leak in somewhere IMHO: snip Is this how is tomcat supposed to work (on SUN's JDK)? Your script will cause TC to run OOM unless the fork option for compiling JSPs is set to true. The fact that in the stock distribution the fork attrribute is set to false by default is IMHO not very good choice. Took me several days of headaches trying to find the leak in my code. When there is a disign choice slow versus crash for 1% of users I would choose slow and put into some doc how to make it faster if it is required. Thanks for your help and best regards, David -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: setting opts to avoid OutOfMemory errors
Hi, Shapira, Yoav wrote: Howdy, The fact that in the stock distribution the fork attrribute is set to false by default is IMHO not very good choice. Took me several days of headaches trying to find the leak in my code. When there is a disign choice slow versus crash for 1% of users I would choose slow and put into some doc how to make it faster if it is required. Well, that's your opinion. ;) I for one disagree. In addition, this issue is well-documented in several places, including the JSPs How-To (http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jasper-howto.html), the Release Notes, the JSP servlet in $CATALINA_HOME/conf/web.xml, this mailing list's archives, and links to this mailing list's archives from the tomcat FAQ Memory page. Workarounds such as precompilingare also documented in at least one of the above places, including pre-compiling your JSPs. Sorry - I was trying to use tomcat 4.1.29 and never looked at 5.0 docs. In 4.1 ones there are really vague advices regarding memory ;-( Also the 4.1.x was for quite a long period of time regarded as stable - not very stable with the default setting. and following bash script: while [ 1 ] do /usr/bin/lynx -dump http://localhost:8080/test.jsp /tmp/m.txt touch /usr/local/jakarta-tomcat-4.1.29/webapps/ROOT/test.jsp If this (the JSP page source changing on every user request) is a realistic scenario for your webapp, you will also run into other, deeper performance- and data-integrity related issues. But why do I get the feeling the above script doesn't mimic any realistic production system scenario? ;) Come on! That was an isolation test case. Of course this is not a production system. On the production system we have approx 20-30 jsps with headers being updated (XMLs fetched and transformed) from another service once in an hour. But this system could stay up no longer than 2 days. If I new that the compilation is a problem I would do it otherwise - but I have suspected our code with the leak. Tried to use insane (http://performance.netbeans.org/insane/) to find the leak and found the tomcat buffers ... Best regards, David Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: setting opts to avoid OutOfMemory errors
Shapira, Yoav wrote: The same is documented in the places I mentioned for the tomcat 4.1 versions, e.g. http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jasper-howto.html. You are right. It is there. I sincerely apologize but I have read only http://jakarta.apache.org/tomcat/faq/memory.html and it was not there, nore in the links mentioned there. Should have searched longer ... So you have an application running on a server that for some reason has a memory leak. This is not a rare problem. You try to track it. You can use a bunch of tools and analyzers, and maybe find the solution yourself. Exactly what I did. Or you can try to search the documentation first, Also did. Unfortunatelly only by using google. which as I mentioned contains information about this issue in several very prominent and easy to find spots. Yes. It contains. prominent and easy to find spots. : Well, that's your opinion. I for one disagree. Having somthing in the docs is cool but if the thing could just work out of the box it would be even better. But you don't have to agree with this. Enough said. Best regards, David Strupl Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: setting opts to avoid OutOfMemory errors
Hi, David Rees wrote: All increasing the -Xmx256M setting will do is delay the onset of the OOM condition, it won't fix it. If you compile a lot of JSPs, make sure that in the container's web.xml you set the fork attribute of the JspServlet to true or use jikes, otherwise that will leak memory as well. With a machine that has 500M, I wouldn't use more than 256M for Tomcat unless nothing else is running on it. -Dave Sorry but how do I set the fork attribute of the JspServlet to true? This seems like an obvoius memory leak in somewhere IMHO: I run tomcat-4.1.29 SUN JDK 1.4.1 (or 1.4.2 if that matters) and creating this test.jsp htmlhead/headbody % System.gc(); out.print(Runtime.getRuntime().freeMemory()); out.print(\t + Runtime.getRuntime().totalMemory()); out.print(\t + new java.util.Date()); % /body/html and following bash script: while [ 1 ] do /usr/bin/lynx -dump http://localhost:8080/test.jsp /tmp/m.txt touch /usr/local/jakarta-tomcat-4.1.29/webapps/ROOT/test.jsp done slowly crashes the tomcat instance. You can watch the progress via tail -f /tmp/m.txt. Is this how is tomcat supposed to work (on SUN's JDK)? Best regards, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
