You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by karthikn <ka...@xius-bcgi.com> on 2008/06/04 15:23:32 UTC
JMX Perform GC TOMCAT 5.5.23
Hi
Jconsole in jdk1.6 has an button called " Perform GC" under MEMORY Tab
For a Production and Live version Tomcat , Can i hook Jconsole via JMX
on the tomcat and force GC process in REMOTE Mode...
Is this permitted or not ?
JMX used as per "http://tomcat.apache.org/tomcat-5.5-doc/monitoring.html"
CATALINA_OPTS="-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8999
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false"
Please advise me on the same
with regards
Karthik
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JMX Perform GC TOMCAT 5.5.23
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Michael Simmons [mailto:Michael.Simmons@uwa.edu.au]
> Subject: RE: JMX Perform GC TOMCAT 5.5.23
>
> So.. giving the JVM many 1000s of times the space taken by
> live objects (even under very high load) is a waste.
Not at all. Having lots of room for short-lived object creation extends the time between GCs.
> Should I have said "Allocating a huge amount of memory to the
> JVM isn't always useful."?
Depends on the characteristics of the application. Usually, the largest heap possible that doesn't push the system in paging is the most efficient.
> In my experience using UseConcMarkSweepGC (or whatever it
> is under 1.6) and tuning the Eden heap size does make a big
> difference to a server application (tomcat) under continuous
> high load.
Not unexpected. The concurrent GC mechanism is designed to minimize pause times but at the expense of quite a bit more overhead during collections. It's not on by default because of the throughput impact; if response time is more important than throughput, then it *might* be useful to enable the concurrent algorithm. You'd have to test in your own environment to see if it's beneficial.
Changing the eden size can also have a dramatic effect on GC frequency, since nearly all objects are created in eden and then moved to a survivor space when eden fills (if still referenceable). If there's an imbalance between eden, survivor, and tenured space sizes, GC efficiency can fall off rapidly. The GC ergonomics feature in 1.5 and 1.6 is an ongoing effort by the HotSpot developers to dynamically balance the heap regions based on current conditions within the JVM; specifying explicit sizes for any of the regions may well end up with worse performance than just letting GC figure it out.
If your webapps create lots of short-lived objects, you might want to experiment with different values for TLABSize; we found that had a major affect on performance in multi-processor systems. Also try setting -XX:+AggressiveHeap; it may or may not be beneficial, depending on your situation.
- 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JMX Perform GC TOMCAT 5.5.23
Posted by Michael Simmons <Mi...@uwa.edu.au>.
Ok, I stand corrected.
>Rather, GC time in a modern JVM depends almost entirely on the number
and size of live objects at
>the time of the collection.
So.. giving the JVM many 1000s of times the space taken by live objects
(even under very high load) is a waste.
Should I have said "Allocating a huge amount of memory to the JVM isn't
always useful."?
In my experience using UseConcMarkSweepGC (or whatever it is under 1.6)
and tuning the Eden heap size does make a big difference to a server
application (tomcat) under continuous high load.
However most of my experience is based on Java 1.4.12
We only recently moved to 1.6 for our app and I have yet to load test.
To Karthik:
>This Tomcat needs to be restarted started every 12+ hrs
VisualGC should help you see whats happening.
If your using the Tomcat database connection pooling it also possible to
see the number of Idle and Active connections in the connection pool.
Context ctx = new InitialContext();
BasicDataSource ds =
(BasicDataSource)ctx.lookup(strDataSource);
intIdleConnections=ds.getNumIdle();
intActiveConnections=ds.getNumActive();
Try displaying these on a status web page within the app along with the
number of active sessions.
Is the number of Active connections growing without bound.
On our app we can also dynamically shorten the inactive session timeout
(from 15 min to 5 mins).
Ie if session count > 800 then all inactive session timeout = 5 mins. We
have a Javascript Timeout counter counting down in every pages status
line to alert the user.
This helps free session data.
I also detect if a new page has been requested less than 250ms ago and
redirect them off the site.
(to stop people hit refresh rapidly as a Denial of server attack)
Michael Simmons
Technical Advisor/Programmer
Information Technology Services (ITS) (Office of Finance and Resources)
Telephone: 6488 4792
Fax: 6488 3861
MBDP: M463
Email: michael.simmons@uwa.edu.au
-----Original Message-----
From: Caldarale, Charles R [mailto:Chuck.Caldarale@unisys.com]
Sent: Thursday, 5 June 2008 10:27 AM
To: Tomcat Users List
Subject: RE: JMX Perform GC TOMCAT 5.5.23
> From: Michael Simmons [mailto:Michael.Simmons@uwa.edu.au]
> Subject: RE: JMX Perform GC TOMCAT 5.5.23
>
> Allocating more memory to the JVM isn't always best.
> Although it means the GC runs less often it causes it to take longer
> to run. Ie large pauses.
Another myth that won't die. Although it was true in some pre-HotSpot
JVMs that GC time was proportional to heap size, that has not been the
case for some time. Rather, GC time in a modern JVM depends almost
entirely on the number and size of live objects at the time of the
collection.
Regardless, make sure the maximum heap plus all the other process space
(for all processes) and whatever the kernel needs doesn't exceed the RAM
on the system; swapping during a GC is something you don't want to see.
- 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe,
e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JMX Perform GC TOMCAT 5.5.23
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Michael Simmons [mailto:Michael.Simmons@uwa.edu.au]
> Subject: RE: JMX Perform GC TOMCAT 5.5.23
>
> Allocating more memory to the JVM isn't always best.
> Although it means the GC runs less often it causes it to take
> longer to run. Ie large pauses.
Another myth that won't die. Although it was true in some pre-HotSpot JVMs that GC time was proportional to heap size, that has not been the case for some time. Rather, GC time in a modern JVM depends almost entirely on the number and size of live objects at the time of the collection.
Regardless, make sure the maximum heap plus all the other process space (for all processes) and whatever the kernel needs doesn't exceed the RAM on the system; swapping during a GC is something you don't want to see.
- 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JMX Perform GC TOMCAT 5.5.23
Posted by karthikn <ka...@xius-bcgi.com>.
Hi
Pardon me for Re Posting the content , had posted the same some day's ago
The Web application is simple and uses JNI to connect to UNIX LOCAL
Application
O/s = UNIX 11 PA Risc 2 CPU
SDK : J2SDK16
TOMCAT 5.5.23
RAM = 8 GB
JAVA_OPTS="-server -Xms200m -Xmx2548m -XX:+UseParallelGC -verbose:gc"
SERVER.xml
<!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
<Connector port="8080" maxHttpHeaderSize="8192"
maxThreads="400" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="10000" disableUploadTimeout="true" />
Am i doing wrong anything in here.....
with regards
Karthik
Michael Simmons wrote:
> I havent used JMX so this might not be relevant
> But I'd suggest the following.
>
> 1) Install jvmstat it works with java 1.6 and use Visualgc to visual
> monitor the garbage collection.
> Note: you need to run tomcat as the same user as the account running
> visualgc
> use "jps" to find out the java vm ID
>
> 2) Use the server jvm (ie one in JAVA_HOME/jre/bin/server
>
> 3) Tweak your GC settings (try seeting your initial memory pool and Max
> mem pool to he same value (say 128MB) and your Thread stack size to say
> 32KB then add the a java options -XX:+UseConcMarkSweepGC -XX:NewSize=32M
> -XX:MaxNewSize=32M).
> Note on windows the Java options need to be on separate lines.
>
> Allocating more memory to the JVM isn't always best.
> Although it means the GC runs less often it causes it to take longer to
> run. Ie large pauses.
> Large pauses can cause timeouts resulting in retries causing more work
> resulting in more pauses and things go down hill from there.
>
> Ensure that your app is closing database connections as soon as it is
> finished with them and that error conditions are correctly handled such
> that database connections are aways closed.
> See "Random Connection Closed Exceptions" in
> (http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.
> html)
> For template code.
>
> Michael Simmons
> Technical Advisor/Programmer
> Information Technology Services (ITS) (Office of Finance and Resources)
> Telephone: 6488 4792
> Fax: 6488 3861
> MBDP: M463
> Email: michael.simmons@uwa.edu.au
>
> -----Original Message-----
> From: karthikn [mailto:karthik.nanjangude@xius-bcgi.com]
> Sent: Wednesday, 4 June 2008 10:16 PM
> To: Tomcat Users List
> Subject: Re: JMX Perform GC TOMCAT 5.5.23
>
> Hi
>
> On a simulator System (same as Production ) with JMeter Load test
>
> performance was good and CPU utilization was not beyond 40% for 900+
> users
>
> But for the same application in Production,
>
> We notice Constantly JAVA is 100% CPU utilization.
>
>
> Any Ideas ?
>
>
> with regards
> Karthik
>
> we were able to
>
> Caldarale, Charles R wrote:
>
>>> From: karthikn [mailto:karthik.nanjangude@xius-bcgi.com]
>>> Subject: Re: JMX Perform GC TOMCAT 5.5.23
>>>
>>> Reason : We have a Production TOMCAT 5.5.23 where in CPU
>>> Utilization for JAVA is going 100% ,
>>>
>>>
>> And for some reason you think a GC will fix that?
>>
>>
>>
>>> This Tomcat needs to be restarted started every 12+ hrs We suspect HP
>>>
>
>
>>> supported JDK1.6 bing the culprit for the same
>>>
>>>
>> A slight possibility, but in nearly all such cases, it's the
>>
> application, not the JVM or Tomcat.
>
>> - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe,
>> e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe,
> e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JMX Perform GC TOMCAT 5.5.23
Posted by Michael Simmons <Mi...@uwa.edu.au>.
I havent used JMX so this might not be relevant
But I'd suggest the following.
1) Install jvmstat it works with java 1.6 and use Visualgc to visual
monitor the garbage collection.
Note: you need to run tomcat as the same user as the account running
visualgc
use "jps" to find out the java vm ID
2) Use the server jvm (ie one in JAVA_HOME/jre/bin/server
3) Tweak your GC settings (try seeting your initial memory pool and Max
mem pool to he same value (say 128MB) and your Thread stack size to say
32KB then add the a java options -XX:+UseConcMarkSweepGC -XX:NewSize=32M
-XX:MaxNewSize=32M).
Note on windows the Java options need to be on separate lines.
Allocating more memory to the JVM isn't always best.
Although it means the GC runs less often it causes it to take longer to
run. Ie large pauses.
Large pauses can cause timeouts resulting in retries causing more work
resulting in more pauses and things go down hill from there.
Ensure that your app is closing database connections as soon as it is
finished with them and that error conditions are correctly handled such
that database connections are aways closed.
See "Random Connection Closed Exceptions" in
(http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.
html)
For template code.
Michael Simmons
Technical Advisor/Programmer
Information Technology Services (ITS) (Office of Finance and Resources)
Telephone: 6488 4792
Fax: 6488 3861
MBDP: M463
Email: michael.simmons@uwa.edu.au
-----Original Message-----
From: karthikn [mailto:karthik.nanjangude@xius-bcgi.com]
Sent: Wednesday, 4 June 2008 10:16 PM
To: Tomcat Users List
Subject: Re: JMX Perform GC TOMCAT 5.5.23
Hi
On a simulator System (same as Production ) with JMeter Load test
performance was good and CPU utilization was not beyond 40% for 900+
users
But for the same application in Production,
We notice Constantly JAVA is 100% CPU utilization.
Any Ideas ?
with regards
Karthik
we were able to
Caldarale, Charles R wrote:
>> From: karthikn [mailto:karthik.nanjangude@xius-bcgi.com]
>> Subject: Re: JMX Perform GC TOMCAT 5.5.23
>>
>> Reason : We have a Production TOMCAT 5.5.23 where in CPU
>> Utilization for JAVA is going 100% ,
>>
>
> And for some reason you think a GC will fix that?
>
>
>> This Tomcat needs to be restarted started every 12+ hrs We suspect HP
>> supported JDK1.6 bing the culprit for the same
>>
>
> A slight possibility, but in nearly all such cases, it's the
application, not the JVM or Tomcat.
>
> - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe,
> e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe,
e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JMX Perform GC TOMCAT 5.5.23
Posted by Mikolaj Rydzewski <mi...@ceti.pl>.
karthikn wrote:
> On a simulator System (same as Production ) with JMeter Load test
>
> performance was good and CPU utilization was not beyond 40% for
> 900+ users
>
> But for the same application in Production,
>
> We notice Constantly JAVA is 100% CPU utilization.
>
>
> Any Ideas ?
Your jmeter load plan is not real...
--
Mikolaj Rydzewski <mi...@ceti.pl>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JMX Perform GC TOMCAT 5.5.23
Posted by Andrew Miehs <an...@2sheds.de>.
On 04/06/2008, at 4:15 PM, karthikn wrote:
>
> We notice Constantly JAVA is 100% CPU utilization.
I am coming in late on this - what OS are u running?
How are you seeing the 100% CPU utilization, with top?
If you have a multiprocessor machine, you may find that top always
shows 100% when the total
of the process time on each processor added together is greater than
100% ie..
cpu 1: 30%
cpu 2: 30%
cpu 3: 30%
cpu 4: 30%
- Top shows 100%....
if you see
cpu 1: 30%
cpu 2: 100%
cpu 3: 30%
cpu 4: 30%
you probably have at least one infinite loop somewhere in your code...
while top is running, press '1' and you will see a list of cpus at the
top (debian linux)
or try running sar: sar -P ALL 1
Cheers
Andrew
RE: JMX Perform GC TOMCAT 5.5.23
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: karthikn [mailto:karthik.nanjangude@xius-bcgi.com]
> Subject: Re: JMX Perform GC TOMCAT 5.5.23
>
> But for the same application in Production,
> We notice Constantly JAVA is 100% CPU utilization.
Which just demonstrates that your test environment is not 100% comprehensive (which, admittedly, is almost impossible to achieve).
What do repeated thread dumps show when the system is in such a state?
- 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JMX Perform GC TOMCAT 5.5.23
Posted by karthikn <ka...@xius-bcgi.com>.
Hi
On a simulator System (same as Production ) with JMeter Load test
performance was good and CPU utilization was not beyond 40% for 900+
users
But for the same application in Production,
We notice Constantly JAVA is 100% CPU utilization.
Any Ideas ?
with regards
Karthik
we were able to
Caldarale, Charles R wrote:
>> From: karthikn [mailto:karthik.nanjangude@xius-bcgi.com]
>> Subject: Re: JMX Perform GC TOMCAT 5.5.23
>>
>> Reason : We have a Production TOMCAT 5.5.23 where in CPU
>> Utilization for JAVA is going 100% ,
>>
>
> And for some reason you think a GC will fix that?
>
>
>> This Tomcat needs to be restarted started every 12+ hrs
>> We suspect HP supported JDK1.6 bing the culprit for the same
>>
>
> A slight possibility, but in nearly all such cases, it's the application, not the JVM or Tomcat.
>
> - 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 start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JMX Perform GC TOMCAT 5.5.23
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: karthikn [mailto:karthik.nanjangude@xius-bcgi.com]
> Subject: Re: JMX Perform GC TOMCAT 5.5.23
>
> Reason : We have a Production TOMCAT 5.5.23 where in CPU
> Utilization for JAVA is going 100% ,
And for some reason you think a GC will fix that?
> This Tomcat needs to be restarted started every 12+ hrs
> We suspect HP supported JDK1.6 bing the culprit for the same
A slight possibility, but in nearly all such cases, it's the application, not the JVM or Tomcat.
- 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JMX Perform GC TOMCAT 5.5.23
Posted by karthikn <ka...@xius-bcgi.com>.
Hi
>> Doing a manual GC at arbitrary times can be disruptive in that it
suspends application threads for the duration.
Reason : We have a Production TOMCAT 5.5.23 where in CPU Utilization for
JAVA is going 100% ,
This Tomcat needs to be restarted started every 12+ hrs
We suspect HP supported JDK1.6 bing the culprit for the same
with regards
Karthik
Caldarale, Charles R wrote:
>> From: karthikn [mailto:karthik.nanjangude@xius-bcgi.com]
>> Subject: JMX Perform GC TOMCAT 5.5.23
>>
>> For a Production and Live version Tomcat, Can i hook
>> Jconsole via JMX on the tomcat and force GC process in
>> REMOTE Mode...
>> Is this permitted or not ?
>>
>
> Depends on what you mean by "permitted". It certainly works, but it's probably not a good idea to push the button - let the JVM take care of GC, that's what it's good at. Doing a manual GC at arbitrary times can be disruptive in that it suspends application threads for the duration.
>
> If you're worried about the security aspects, don't configure JMX without authentication.
>
> - 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 start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JMX Perform GC TOMCAT 5.5.23
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: karthikn [mailto:karthik.nanjangude@xius-bcgi.com]
> Subject: JMX Perform GC TOMCAT 5.5.23
>
> For a Production and Live version Tomcat, Can i hook
> Jconsole via JMX on the tomcat and force GC process in
> REMOTE Mode...
> Is this permitted or not ?
Depends on what you mean by "permitted". It certainly works, but it's probably not a good idea to push the button - let the JVM take care of GC, that's what it's good at. Doing a manual GC at arbitrary times can be disruptive in that it suspends application threads for the duration.
If you're worried about the security aspects, don't configure JMX without authentication.
- 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org