Pointing Multiple contexts to single webapp
I have a single webapp. But this has to be accessed from multiple contexts for example : http://localhost:8080/abc http://localhost:8080/cde http://localhost:8080/xyz I did this using having multiple context tags in the Host tag similar to the following Context path=abc docBase=MY_WEBAPP_FOLDER / Context path=abc docBase=MY_WEBAPP_FOLDER / Context path=abc docBase=MY_WEBAPP_FOLDER / The problem with this is, it is duplicating all the resources in the webapp and starting up all the path by loading all resources. As a reason, I am getting MemoryOutOfErrors. I want this to be done with single resource. Any help?? - Kishore
Cleartrust RSA integration
Hi All We are thinking of bringing some of our apps off proprietary J2EE servers to Tomcat. We would be deploying on Tomcat 6 (latest), JVM 1.6 and Linux on a VM (not sure of versions). One of the requirements is to authenticate using RSA Cleartrust. From my reading, Tomcat does not support this. The recommended solution is to front Tomcat with Apache, and let Apache do the Cleartrust integration. The links I have found are a bit ancient - are my assumptions still correct? Also, our system architects seem to think this setup is insufficiently secure - comments? Regards Ron - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting the Right Amount of Memory
Caldarale, Charles R wrote: On Jun 19, 2010, at 18:31, André Warnier a...@ice-sa.com wrote: As Mark writes above (and my interpretation of things) : - a bigger Heap means that the JVM will be able to accumulate more dead stuff in it, - when it is needed however, it will take much longer, because there is more stuff to clean up. I thought we had taught you better than that... Ooops. The time it takes to perform a GC is *not* dependent on the number or size of dead objects, just on the live ones. That is counter-intuitive. Pray, why is that ? (Or point again to a page describing the process, maybe. That would be useful for the OP also). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[OT] Re: Setting the Right Amount of Memory
Caldarale, Charles R wrote: (Sent from my iPhone on a ferry in the middle of Lake Michigan.) Posters to this forum, observe the incredible dedication of some of the contributors here. I'm willing to bet that if the ferry was sinking, Chuck would be the last one on board, making sure there wasn't any unanswered message on this forum (or at least any wrong and uncorrected answer lingering). We should have a competition about whom can post a message from the most unlikely location, or circumstances. The middle of lake Michigan isn't bad for a start. We would need some means of checking though. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Pointing Multiple contexts to single webapp
Kishore Kumar Manthangod wrote: I have a single webapp. But this has to be accessed from multiple contexts for example : http://localhost:8080/abc http://localhost:8080/cde http://localhost:8080/xyz Have a look at UrlRewriteFilter : http://www.tuckey.org ... As a reason, I am getting MemoryOutOfErrors. Have you thought of patenting that code ? A lot of vendors would be interested in something like that. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cleartrust RSA integration
Ron McNulty wrote: Hi All We are thinking of bringing some of our apps off proprietary J2EE servers to Tomcat. We would be deploying on Tomcat 6 (latest), JVM 1.6 and Linux on a VM (not sure of versions). One of the requirements is to authenticate using RSA Cleartrust. From my reading, Tomcat does not support this. The recommended solution is to front Tomcat with Apache, and let Apache do the Cleartrust integration. The links I have found are a bit ancient - are my assumptions still correct? Also, our system architects seem to think this setup is insufficiently secure - comments? Assuming the Apache Cleartrust authentication is secure.. If Apache authenticates a request, and if the Apache/Tomcat connector is mod_jk, then the authenticated user-id is propagated from Apache to Tomcat (*). (Additionals info could be propagated via additional HTTP headers, or request attributes). If the link between Apache and Tomcat is secure (like for example both run on the same machine and the connection is purely internal), then there is no reason why this would be less secure. (*) whether Tomcat actually uses it, is determined by the tomcatAuthentication attribute of the AJP Connector. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Re: Setting the Right Amount of Memory
On 20/06/2010 10:25, André Warnier wrote: Caldarale, Charles R wrote: We would need some means of checking though. Some means of registering a check in, by location? Hmm. I wonder if anyone's had that idea before... ;) p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org signature.asc Description: OpenPGP digital signature
Re: Setting the Right Amount of Memory
On 20/06/2010 00:30, André Warnier wrote: Robinson, Eric wrote: On 17/06/2010 08:59, Robinson, Eric wrote: If your heap size is right on the edge of your minimum for a Tomcat instance, you may be doing more GC work than is really needed. However, if you're satisfied with the response time and CPU utilization, you should be ok. Time to hit the vendor around the head with the cluebat. If the app is happy with less heap space then increasing it is only going to cause problems - mainly that GC when it happens will take longer and trigger longer pauses. You can mitigate this with GC config (later VMs may make the right choices for you anyway) but all this is just adding unecessary complexity. Mark With 160 instances of tomcat on the server, and most of them happy with 64-96MB of RAM, could you take an educated guess at the negative impact on the server of raising the RAM to 512MB for each instance? How much extra CPU utilization do you think I could possibly see from all the extra GC? Just a note here : 160 X 512 MB = 81 GB. If each Tomcat's JVM is allowed to use up to 512 MB of Heap, there might be moments where a lot of JVM's will be using close to that amount. Unless your system can really support that amount of real RAM, you may be in for massive swapping. And that could be a major problem. JVMs and swapping do not place nicely together. To quote some folks at work that have been looking at this recently performance falls of a cliff. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting the Right Amount of Memory
On 20/06/2010 10:24, André Warnier wrote: Caldarale, Charles R wrote: On Jun 19, 2010, at 18:31, André Warnier a...@ice-sa.com wrote: As Mark writes above (and my interpretation of things) : - a bigger Heap means that the JVM will be able to accumulate more dead stuff in it, - when it is needed however, it will take much longer, because there is more stuff to clean up. I thought we had taught you better than that... Ooops. Me too. I was under the impression more dead objects == longer GC. The time it takes to perform a GC is *not* dependent on the number or size of dead objects, just on the live ones. That is counter-intuitive. Pray, why is that ? +1. I'd to get me head around this. (Or point again to a page describing the process, maybe. That would be useful for the OP also). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting the Right Amount of Memory
On Jun 20, 2010, at 4:24, André Warnier a...@ice-sa.com wrote: The time it takes to perform a GC is *not* dependent on the number or size of dead objects, just on the live ones. That is counter-intuitive. Pray, why is that ? All modern GC algorithms are variations of mark-sweep-compact. The basic operation consists of following the object reference graph from a set of known roots (eg, thread stack frames), marking each discovered object with a found flag, and copying the found objects to an unoccupied area. Unreachable (dead) objects are never encountered, so their number or size does not come into play. The space occupied by dead objects is automatically reclaimed as live objects are copied over them. There are links to various papers and descriptions on the Java technologies page: http://java.sun.com/javase/technologies/hotspot/gc-index.jsp Googling for mark-sweep-compact will get you some of the academic papers and continuing research into the topic. - Chuck (Now in a hotel watching the All Whites vs the Azzurri.)
Re: Setting the Right Amount of Memory
On 20.6.2010 14:06, Mark Thomas wrote: On 20/06/2010 00:30, André Warnier wrote: Just a note here : 160 X 512 MB = 81 GB. If each Tomcat's JVM is allowed to use up to 512 MB of Heap, there might be moments where a lot of JVM's will be using close to that amount. Unless your system can really support that amount of real RAM, you may be in for massive swapping. And that could be a major problem. JVMs and swapping do not place nicely together. To quote some folks at work that have been looking at this recently performance falls of a cliff. Yep, I've seen that as well -- and the effect really is easy to understand, esp. in the light of how Chuck explained the mark-sweep-compact memory management. The live objects are somewhat scattered throughout the heap, and walking through the live object graph will touch all of them -- thus if any was paged out at the moment, it will be paged in (most likely forcing some other page out). If majority of the OS-level virtual memory consumption consists of JVM heaps, then it's very likely that the paged-out memory page does contain a live Java object - which will again be paged in when the owning JVM does its mark phase. Paging is suitable OS-level memory management for processes with full pages of data that only needs to be accessed infrequently (or perhaps only in the initialization phase of the application). Then these seldom-accessed pages can be moved out to disk, freeing RAM for more frequently needed items. With JVM memory management, everything is accessed every now and then, making paging a real performance-killer. -- ..Juha - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting the Right Amount of Memory
On 20 June 2010 16:01, Caldarale, Charles R chuck.caldar...@unisys.comwrote: All modern GC algorithms are variations of mark-sweep-compact. The basic operation consists of following the object reference graph from a set of known roots (eg, thread stack frames), marking each discovered object with a found flag, and copying the found objects to an unoccupied area. Unreachable (dead) objects are never encountered, so their number or size does not come into play. The space occupied by dead objects is automatically reclaimed as live objects are copied over them. Note that in some variants, the cost of a compact *does* vary with the number of dead objects. In Squeak (Smalltalk), for example, each object header contains the object size, and hence by implication the address of the next object header. Squeak's GC compacts (after the mark phase) by starting at the bottom of object memory and iterating through each object, copying down the live ones and updating pointers on the way. In Java, this would only ever be necessary in OldSpace - with a generational GC where you're collecting anything other than the oldest generation, you just copy the live objects out as you encounter them and update any pointers to other objects in the same generation, after which you know the space is empty. Typically, the speed of such a compact is limited by the speed of access to memory. Most modern memory architectures will treat such sequential read access specially and start to read-ahead, so the memory overhead isn't as bad as it might be. My GC knowledge is a little out of date, so if any of the current GC experts wish to correct me I'll be interested! - Peter
How to speed up tomcat 5.5 jsp precompilation?
Hi all,
I have 2100 jsp files in my system, and I use the following ant script
to precompile my jsp files. It takes 10 minutes to complete. 10 minutes is too
long for me, because I also need to run class obfuscation, js/css compressor
and test case. It’s any tips for me to speed up the precompilation?
==
The following is my ant script:
target name=common.compilejsp
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath id=jspc.classpath
pathelement location=${java.home}/../lib/tools.jar /
fileset dir=${tomcat.home}/bin
include name=*.jar /
/fileset
fileset dir=${tomcat.home}/server/lib
include name=*.jar /
/fileset
fileset dir=${tomcat.home}/common/lib
include name=*.jar /
/fileset
/classpath
/taskdef
delete failonerror=false dir=${build.dir}/jspsrc/
mkdir dir=${build.dir}/jspsrc/
echo${jsp.srcdir}/echo
jasper2 validateXml=false uriroot=${jsp.srcdir}
webXmlFragment=${basedir}/generated_web.xml
outputDir=${build.dir}/jspsrc
/jasper2
javac destdir=${jsp.compilation.destdir} optimize=off
debug=off failonerror=${failonerror.during.compilation}
srcdir=${build.dir}/jspsrc
encoding=UTF-8 fork=true memoryMaximumSize=1280M
classpath
pathelement location=${8th.classes.dir} /
fileset dir=${8th.lib.dir}
include name=*.jar /
/fileset
pathelement location=${tomcat.home}/common/classes /
fileset dir=${tomcat.home}/common/lib
include name=*.jar /
/fileset
pathelement location=${tomcat.home}/shared/classes /
fileset dir=${tomcat.home}/shared/lib
include name=*.jar /
/fileset
fileset dir=${tomcat.home}/bin
include name=*.jar /
/fileset
/classpath
include name=**/*.java /
/javac
/target
Regards,
Eric chen
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC driver of class '' for connect URL 'null' AGAIN!
How do I unsubscribe from this list? I have tried following the unsubscribe link in the emails and it has not worked... Any tips would be appreciated. -Original Message- From: David Smith [mailto:david.sm...@cornell.edu] Sent: 19 June 2010 22:36 To: Tomcat Users List Subject: Re: org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC driver of class '' for connect URL 'null' AGAIN! On 6/19/2010 1:31 PM, yucca...@live.co.za wrote: I have no choice left but to not let hibernate use my tomcat datasource. This is not good. I have even moved host provider in hope that it was previous fult tomcat install from dailyrazor (tomcat 6 does not hav common/lib) and is meant to have tomcat/lib I can say that my new container is correct and that I am 100% sure that all mus jdbc configuration is correct in zml after having gone though it at least 20 times and checked the wiki that was linked here earlier and still have issues. Yes mysql jdbc bin is in tomcat/lib so that is not cause of the error. /the error is very weird though as I have another point that uses hibernate without error on the same database. It is not possible for me to use hibernate to use tomcat datasource sadly. Many thanks for all the help though. If you put the following into a jsp and call the jsp, does it work? %...@page import=java.sql.Connection% %...@page import=java.sql.DriverManager% %...@page import=java.sql.SQLException% % Class.forName(com.mysql.jdbc.Driver).newInstance(); conn = DriverManager.getConnection(jdbc:mysql://localhost/test? + user=montypassword=greatsqldb); out.println( The connection worked!! ) ; % If that works then your jdbc driver is available and installed properly (I trust there is only one copy of that jar in your entire tomcat install ... right?). Now check to see if there's an xml in tomcat/conf/Catalina/localhost matching your webapp's deployed name. For instance if you access your webapp as http://localhost:8088/mywebapp, there should be a mywebapp.xml file there. Take a look at it for the Resource ... / or ResourceLink ... / (which ever you setup) and make sure they are correct. If this file is not available, take a look at context.xml in your webapp's META-INF folder (same process). If it's not there, then the Context ... element for your webapp is in server.xml and it should NOT be there. It's bad practice and requires a full tomcat restart to make changes. Lastly, case matters. Be sure everything is typed correctly including whether it's upper or lower case. Now take a look at the logs and post any relevant messages including complete stacktraces of exceptions w/o edits except to protect usernames and passwords. --David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat.exe 6.0.18 to 6.0.26 stdout/stderr redirection
Hi All,
Before we upgraded from Tomcat 6.0.18 to 6.0.26 I was able to redirect
stdout/stderr of tomcat.exe using the following Python code;
from subprocess import Popen
logfile = open('tomcat.log', 'w')
p = Popen(r'C:\Program Files\Apache Software Foundation\Tomcat
6.0\bin\tomcat6.exe', shell=True, stdout=logfile, stderr=logfile)
but with 6.0.26, the above code fails to redirect the output to tomcat.log,
all of the output goes to the console (cmd.exe).
Has something changed in 6.0.26 (Windows) that would effect this behaviour ?
Cheers
---
Bulkan Evcimen
RE: Setting the Right Amount of Memory
Having a borderline heap size can, in the worst case, result in almost continual GC activity, if there is only room to allocate a minimal number of objects between GC occurrences. For what it's worth, either this is not the case in our real-world situation or the effect is negligible. Even though we have 160 instances of tomcat on the same server, and all of them are trimmed to use the minimum RAM (usually 64-96MB) and all instances are quite actively being used, the server is still 90% idle during peak load. The server is an 8-core 2.6GHz Xeon with 32GB RAM (10GB free and no swapping). Disclaimer - June 20, 2010 This email and any files transmitted with it are confidential and intended solely for Tomcat Users List. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of . Warning: Although has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Setting the Right Amount of Memory
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Subject: Re: Setting the Right Amount of Memory Unreachable (dead) objects are never encountered, so their number or size does not come into play. For complete disclosure, I should note that dead objects in the tenured (old) and permanent generations are looked at (but only during a full GC), since the compaction phase has to figure out where the live ones can be copied to. However, since in nearly all cases, more than 90% of dead objects are in the young generation, few dead objects are examined and the cost is minimal. The compaction phase for the young generation (minor GC) actually consists of copying the live objects to a survivor space, which is guaranteed to be empty. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
RE: Setting the Right Amount of Memory
From: Robinson, Eric [mailto:eric.robin...@psmnv.com] Subject: RE: Setting the Right Amount of Memory Having a borderline heap size can, in the worst case, result in almost continual GC activity, if there is only room to allocate a minimal number of objects between GC occurrences. For what it's worth, either this is not the case in our real-world situation or the effect is negligible. Not surprising - you'd have to be very unlucky to be right at the edge and see a lot of GC activity and be able to continue running. Usually you'll be over the edge a bit, encounter OOMEs, increase the heap significantly, and be well away from the frequent tight heap scenario. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat.exe 6.0.18 to 6.0.26 stdout/stderr redirection
If you're running as a service, why don't you make use of --StdOutput and
--StdError as documented here:
http://tomcat.apache.org/tomcat-6.0-doc/windows-service-howto.html
Also, if you're running as a service, the Tomcat Monitor allows you to change
this at any point. There's a tab called Logging that allows you to set a bunch
of parameters.
/mde/
--- On Sun, 6/20/10, Bulkan bul...@gmail.com wrote:
From: Bulkan bul...@gmail.com
Subject: tomcat.exe 6.0.18 to 6.0.26 stdout/stderr redirection
To: users@tomcat.apache.org
Date: Sunday, June 20, 2010, 6:06 PM
Hi All,
Before we upgraded from Tomcat 6.0.18 to 6.0.26 I was able
to redirect
stdout/stderr of tomcat.exe using the following Python
code;
from subprocess import Popen
logfile = open('tomcat.log', 'w')
p = Popen(r'C:\Program Files\Apache Software
Foundation\Tomcat
6.0\bin\tomcat6.exe', shell=True, stdout=logfile,
stderr=logfile)
but with 6.0.26, the above code fails to redirect the
output to tomcat.log,
all of the output goes to the console (cmd.exe).
Has something changed in 6.0.26 (Windows) that would effect
this behaviour ?
Cheers
---
Bulkan Evcimen
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Setting the Right Amount of Memory
For what it's worth, either this is not the case in our real-world situation or the effect is negligible. Not surprising - you'd have to be very unlucky to be right at the edge and see a lot of GC activity and be able to continue running. Usually you'll be over the edge a bit, encounter OOMEs, increase the heap significantly, and be well away from the frequent tight heap scenario. What qualifies as a tight heap and what qualifies as a significant increase? Usually when we see OOMEs we increase the allocation by 32MB and they go away. To return to the original question, is it generally better to custom-fit the RAM allocation (as we currently do) or to unilaterally set all instances to a higher amount that we know will not generate OOMEs, such as 512MB? -- Eric Robinson Disclaimer - June 20, 2010 This email and any files transmitted with it are confidential and intended solely for Tomcat Users List. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of . Warning: Although has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Setting the Right Amount of Memory
From: Robinson, Eric [mailto:eric.robin...@psmnv.com] Subject: RE: Setting the Right Amount of Memory What qualifies as a tight heap and what qualifies as a significant increase? Both are entirely dependent on what's running inside the JVM. Monitoring the GC actions will tell you if you're close to being tight. Usually when we see OOMEs we increase the allocation by 32MB and they go away. From your descriptions, none of your webapps are memory-intensive, so 32 MB is likely a significant increase in the heap size - in your case. is it generally better to custom-fit the RAM allocation (as we currently do) or to unilaterally set all instances to a higher amount that we know will not generate OOMEs, such as 512MB? Depends on how much time you've got to spend on the problem, and how much RAM you've got. If the RAM is available, it's certainly easier to set the heap size large for everyone and let it rip. If you are constrained such that doing so will result in an overcommitment of RAM (or you like things to be just right), then you need to individually tune. You might actually have a situation where it would work to set -Xms small (16 or 32 MB) and -Xmx large (512 MB), and let each JVM figure out what it really needs. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat.exe 6.0.18 to 6.0.26 stdout/stderr redirection
Hi Mark,
I am not running tomcat as a service. I directly start tomcat.exe
Cheers
On Mon, Jun 21, 2010 at 1:41 PM, Mark Eggers its_toas...@yahoo.com wrote:
If you're running as a service, why don't you make use of --StdOutput and
--StdError as documented here:
http://tomcat.apache.org/tomcat-6.0-doc/windows-service-howto.html
Also, if you're running as a service, the Tomcat Monitor allows you to
change this at any point. There's a tab called Logging that allows you to
set a bunch of parameters.
/mde/
--- On Sun, 6/20/10, Bulkan bul...@gmail.com wrote:
From: Bulkan bul...@gmail.com
Subject: tomcat.exe 6.0.18 to 6.0.26 stdout/stderr redirection
To: users@tomcat.apache.org
Date: Sunday, June 20, 2010, 6:06 PM
Hi All,
Before we upgraded from Tomcat 6.0.18 to 6.0.26 I was able
to redirect
stdout/stderr of tomcat.exe using the following Python
code;
from subprocess import Popen
logfile = open('tomcat.log', 'w')
p = Popen(r'C:\Program Files\Apache Software
Foundation\Tomcat
6.0\bin\tomcat6.exe', shell=True, stdout=logfile,
stderr=logfile)
but with 6.0.26, the above code fails to redirect the
output to tomcat.log,
all of the output goes to the console (cmd.exe).
Has something changed in 6.0.26 (Windows) that would effect
this behaviour ?
Cheers
---
Bulkan Evcimen
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 5.5.26 with application is having memory/performance issue
Hi, I have the memory issue/performance with the following situation: a. The machine installed with Solaris 10, with memory 2GB and swap space 4GB. b. Running Tomcat 5.5.26 with one application at Xmx1024m and -Xmx256m using JDK1.5.0_22. c. 10 standalone clients are sending the web service request to application for processing the task using xmlrpc.jar continuously. d. The script is used to get the system properties, e.g. java.home, java.class.path, os.name, etc and then construct the http response send back the client. e. After 1 week plus, the web users require very long time to login and somehow the page cannot be displayed. I have done the following to monitor the issue: a. Monitor the rss, vsz using ps -eo command, found that the rss and vsz were increased slightly over time, until hitting 1.70G where the web users experience slow performance on the page navigation in the tomcat. b. I ran the Tomcat by putting the -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC, then analyzed that the gc heap over time is constant. c. Use jconsole to record the heap and non-heap usage, triggerring Full GC, observed that the heap is reset to zero and the non-heap won't drop. Non-heap memory usage is increased over time. d. Don't know the reason why cannot get the Tomcat runs into OutOfMemory, the Tomcat shutdown itself without anything even the argument -XX:+HeapDumpOnOutOfMemoryError is applied. Did I missed out anything to track down the issue? Anyone, please suggest and correct me. Thanks. Regards, Chan. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
