date:20101008

On 08/10/2010 00:07, Rob G wrote:
 Thanks to all for their replies to date. Much appreciated, I'll
 respond to some of the points raised. Apologies if I'm asking basic
 stuff but still getting my ahead around Tomcat and Apache integration.
 
 On 7 October 2010 18:31, André Warnier wrote:
 
 Your configuration looks very clean to me (no unnecessary settings etc.),
 which in this case is a plus (a good base to start tuning).
 Thank you
 
 You may want to upgrade Tomcat to the latest version (6.0.29).
 Noted
 
 For example, at the moment these errors happen, what are these Tomcats
 really doing ?
 Are they really busy each processing 200 requests, with 200 threads running
 and actually doing something ? (200 is the default for the maxThreads
 attribute of the AJP Connector).
 Unfortunately I'm not in a position to conduct realtime monitoring of
 the server and Tomcat. Is there a way to log this thread data?

How do you get log data?

 If yes, then you may just need a leaner application, or a bigger system
 (more RAM, faster CPU), or more systems.  What does the Task Manager tell
 you about the total system load ?
 Again, unfortunately not in a position to monitor  in real time.

You can enable JMX and connect remotely on a specified port to get a
look inside the JVM

 If not, and many of these threads are waiting, then you may have an issue
 with a keepAlive that is too long.
 See http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html, for the
 connectionTimeout and keepAliveTimeout attributes.
 Will do
 
 Whatever you do, first get an idea of the starting situation.  Then modify
 one setting at a time, and observe (and note) the effects.
 Sensible advice
 
 Pid wrote:
 OK.  Is there anything else different apart from the Servlet container?
 I'm not sure what you mean?

Did you change DB too, or is was it a simple migration?

 Why do you have two Tomcat instances?  (It's not a trick question, I'm 
 interested in your reasoning.)
 Load balancing. I thought/guessed that two instances would be
 sufficent. Perhaps this was incorrect and I need more?

Maybe, maybe not.

I was trying to understand why you had two instances, rather than one
with, say, more threads configured.

Load balancing two Tomcat instances which are both using the same
underlying computing resource will not offer a tangible benefit in terms
of throughput / response time compared to a suitably configured single
instance.

If you're on a 32bit system and are hitting process memory limits, you
might need two instances to cope with the load.


 How many threads  server instances did you have before?
 What were your Java -Xmx etc settings before, and now?

 Are you using an Executor?
 I'll have to check, but I think it's safe to say that they are set to
 the default values as I don't recall changing anything relating to
 them.

 Thread dumps from a maxed out Tomcat will tell you what each Thread is 
 waiting for.  Collect a series of these during high load periods to find
 out what's happening.
 I'll have to figure out how to do this, but sounds a good idea.

Do you have remote access to the machine?

There are command line tools with JDK 6 (6.0.21 is the latest) which are
useful.  E.g. jstack, jmap.

If you have remote access to the GUI, JDK 6 also has JConsole and
VisualVM which provide metric tonnes of useful information.

Otherwise you can connect those tools, for slightly less output,
remotely via JMX.  Be sure to use :

 org.apache.catalina.mbeans.JmxRemoteLifecycleListener
 http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html


Please also check the port numbers you have in use for each Tomcat
instance.  Are the Tomcats installed and run as a service?


p

 Christopher Schultz wrote
 I think you might want to compare the request processor counts you have for 
 Tomcat versus mod_jk: the default maxThreads for a Tomcat Connector is 
 200, while your MaxClients settings might be different on your Apache httpd 
 configuration.
 Excuse my ignorance, but can you clarify where I check these settings?
 
 I believe that only the Worker MPM is available on Microsoft Windows. Have 
 you explicitly configured an MPM?
 Since I don't know what an MPM is I'm going to say no.
 
 Since you're using Apache 2.x, mod_jk should be able to auto-configure this 
 value for you.
 Do I need to set anything to allow this auto config to happen?
 
 From my reading, you may be limiting yourself to 10 simultaneous connections 
 from Apache httpd to Tomcat, and others will get a 503.
 What lead you to that conclusion?
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 



0x62590808.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Tomcat auf MS Cluster?

On 07/10/2010 18:07, Jeffrey Janner wrote:
 -Original Message-
 From: Mark Thomas [mailto:ma...@apache.org]
 Sent: Wednesday, October 06, 2010 9:31 AM
 To: Tomcat Users List
 Subject: Re: Tomcat auf MS Cluster?

 On 06/10/2010 15:16, Jeffrey Janner wrote:
 I agree with Mark, upgrade your Tomcat to a supported rev.
 If possible, go to the latest 6.0, otherwise, 5.5.x would be good,
 but
 it will become unsupported shortly when 7.0.x becomes official.

 Less supported maybe. The rough guide is:
 - 7.0.x - enhancements, bug fixes  security fixes
 - 6.0.x - bug fixes  security fixes
 - 5.5.x - security fixes

 But that is only a very rough guide. A lot of enhancements are making
 it
 into 6.0.x and 5.5.x is still getting bug fixes.

 The last time the devs officially declared something unsupported
 (4.1.x)
 there was a 12 month notice period and I assume the same would be true
 when 5.5.x finally reaches end of life.

 Mark

 Thanks for the update Mark.
 As a heavy 5.5.x user, that is reassuring.

5.5 - 6.0 isn't a big deal in my experience, and doesn't seem to be
from the lack of complaints here on the list.

p

 __

 Confidentiality Notice:  This Transmission (including any attachments) may 
 contain information that is privileged, confidential, and exempt from 
 disclosure under applicable law.  If the reader of this message is not the 
 intended recipient you are hereby notified that any dissemination, 
 distribution, or copying of this communication is strictly prohibited.  

 If you have received this transmission in error, please immediately reply to 
 the sender or telephone (512) 343-9100 and delete this transmission from your 
 system.

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

0x62590808.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature

Re: deploy to public_html folder

On 08/10/2010 00:49, Sreeprasad Govindankutty wrote:
 Upload the .WAR archive to /public_html/servlet
 Extract .WAR archive using Shell access using the unzip command

Unless you have inside knowledge about the OPs environment, that's poor
advice.

 On Thu, Oct 7, 2010 at 6:54 PM, William Biggs kc8...@gmail.com wrote:
 
 I would like to know how to deploy a war to the public_html ?

Did you ask this question recently?

Apache Tomcat != Apache HTTPD

The methods for deploying sites are very different.

Please provide the following information: what are the exact Tomcat, JVM
and OS versions you are using?


p



0x62590808.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Disable class monitoring for reloading container classes

2010-10-08 Thread Mark Thomas

On 08/10/2010 01:11, Jane Muse wrote:
 This happens with both DST and standard time changes. What's interesting
 is if we go back in time to Oct 29 2006, it does not occur. From March
 2007 forward, every fall and spring we get the error when the
 application reloads. The DST time change rules changed in March 2007 for
 USA time zone.

Random thought. Have the necessary timezone updates been applied to the
OS and to Java? If they are out of sync that could make time appear to
jump to the JVM.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Disable class monitoring for reloading container classes

On 08/10/2010 01:19, Jane Muse wrote:
 If I changed the system time zone not to change with daylight savings
 time, then it would be off by an hour. I don't think our customers would
 like that. Or am I misunderstanding your comment?

The system timezone is almost irrelevant, you could use UTC or any other
stable timezone setting.

The primitive long value of time inside a Date is the same regardless of
timezone.  It sounds like you're relying on the system time for date
display, rather than formatting it as needed when you need to output it.


p

 Thanks,
 
 Jane 
 
 -Original Message-
 From: Pid [mailto:p...@pidster.com] 
 Sent: Thursday, October 07, 2010 8:23 AM
 To: Tomcat Users List
 Subject: Re: Disable class monitoring for reloading container classes
 
 On 06/10/2010 20:39, Jane Muse wrote:
 There's a backgroundProcessor method in tomcat that checks whether 
 container classes need to be reloaded, and checks for session 
 expirations. Is it possible to disable this method, like you can 
 disable class reloading for the context with reloadable=false? I'm 
 using tomcat 6.0.18 on an IBM i (OS400)  version V6R1. When daylight 
 savings time hits, our application gets reloaded, and the following 
 statements are in catalina.out:
 
 How about fixing the system time zone to be one that doesn't change with
 daylight time savings?
 
 
 p
 
 Mar 14, 2010 3:00:08 AM org.apache.catalina.core.StandardContext 
 reload


 INFO: Reloading this Context has started

  
 We have been able to stop the application from reloading on a 
 different version of the IBM i, version V7R1, by using 
 reloadable=false. However on the V6R1 O/S the application still 
 reloads because the background processor detects a timestamp change
 when DST occurs.
  
 From the documentation, it doesn't look like backgroundProcessorDelay 
 can be used to suppress backgroundProcess, just to delay it as its 
 name implies.
  
 We would gladly upgrade tomcat to a more recent version if we thought 
 this issue had been resolved, but I don't see any mention of it in the
 
 change logs.
  
 - Jane

 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 



0x62590808.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Error 503 ocurring when server under load


Pid wrote:
...


Is this info in the original email?  

Yes.

(If so, I think my mailer isn't

behaving well).


It seems also somewhat spastic.  We've been receiving multiple copies of what 
you send.
Or did you just have too much coffee lately ?


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Disable class monitoring for reloading container classes


Jane Muse wrote:

If I changed the system time zone not to change with daylight savings
time, then it would be off by an hour. I don't think our customers would
like that. Or am I misunderstanding your comment?


Maybe Pid's comment was partly tongue-in-cheek.

You did not misunderstand, but of course it all depends on what your application does, and 
on whether the system's time difference is visible to them or not.


On this :

This happens with both DST and standard time changes. What's interesting
is if we go back in time to Oct 29 2006, it does not occur. From March
2007 forward, every fall and spring we get the error when the
application reloads. The DST time change rules changed in March 2007 for
USA time zone.

Somehow this suggest to me that there is something else going on.
I have not re-done Christopher's reasoning in detail - and Pid seemed to agree, so I'm not 
going to - and I have also not gone to look at the actual code, but superficially it does 
not look to me as if a simple time change would trigger any application reload.
It would have to be the combined effect of a change to a file's last modified stamp 
/and/ a system time change, no ?



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: apache-tomcat-6.0.29 will not start with more then 1024mb memory assigned - windows

2010-10-08 Thread Hans Magne Helland

 So you would need 64 Bit versions of those libraries which are coming from
 BMC. I would be interested in the info whether they exist as well :)

I now run ARS 7.6, with the newest Mid-Tier 7.6 on my test server and
it runs with 64 bit Java :)

But now it uses a lot of CPU. Googled it, and saw people having
CPU-usage issues with ESX Vmware and Tomcat. Is this a known thing?

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: apache-tomcat-6.0.29 will not start with more then 1024mb memory assigned - windows


Hans Magne Helland wrote:

So you would need 64 Bit versions of those libraries which are coming from
BMC. I would be interested in the info whether they exist as well :)


I now run ARS 7.6, with the newest Mid-Tier 7.6 on my test server and
it runs with 64 bit Java :)

But now it uses a lot of CPU. Googled it, and saw people having
CPU-usage issues with ESX Vmware and Tomcat. Is this a known thing?

As a bit of an outsider, I'd tell you that the CPU and RAM usage are a known thing, not 
particularly with Vmware or Tomcat, but with anything Java.

The switch to 64-bit merely seems to double it.

But the guys on this list are all Java freaks, so they would probably not understand what 
we're talking about.  Or else they do, and they all have shares in Intel and Kingston.

:-)


On the serious side : I have several virtual servers running Tomcat under Vmware Server 
(not ESX), and I did not notice anything particular about their CPU or RAM usage, as 
compared to physical servers.  Only the same thing. :-)



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: apache-tomcat-6.0.29 will not start with more then 1024mb memory assigned - windows

2010-10-08 Thread Caldarale, Charles R

 From: Hans Magne Helland [mailto:hansma...@gmail.com] 
 Subject: Re: apache-tomcat-6.0.29 will not start with more then 1024mb memory 
 assigned - windows

 But now it uses a lot of CPU. Googled it, and saw people having
 CPU-usage issues with ESX Vmware and Tomcat.

Time to start a new thread, since the above is completely unrelated to the 
subject line.

 - 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: Error 503 ocurring when server under load

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rob,

On 10/7/2010 7:07 PM, Rob G wrote:
 Christopher Schultz wrote
 I think you might want to compare the request processor counts you
 have for Tomcat versus mod_jk: the default maxThreads for a Tomcat
 Connector is 200, while your MaxClients settings might be
 different on your Apache httpd configuration.

 Excuse my ignorance, but can you clarify where I check these settings?

Obviously, the worker settings are in your Workers.properties file that
you've already posted. The settings for Apache httpd are usually in a
file called conf/httpd.conf in the Apache httpd installation directory.
On win32, that might be something like C:\Program Files\Apache
Foundation\Apache Web Server\conf\httpd.conf

Tomcat's server settings are in conf/server.xml in the Apache Tomcat
installation directory. On win32, that might be something like
C:\Program Files\Apache Foundation\Apache Tomcat\conf\server.xml

Since you have two copies of Tomcat working, you should check both of
them. In fact, if you could post the server.xml files from both
instances and tell us how you have them configured to run side-by-side,
that would be helpful.

Pid pointed out that you might not have both instances running due to a
shutdownPort conflict. That might also be the case if you have other
ports that conflict.

 I believe that only the Worker MPM is available on Microsoft Windows. Have 
 you explicitly configured an MPM?

 Since I don't know what an MPM is I'm going to say no.

:) That stands for Multi-Processing Module and it's how the Apache Web
Server serves more than one request at a time. On *NIX, you can choose
the prefork module which gives you one child process per simultaneous
request, or the worker module which gets you a single (child?) process
with many threads running within it. I just checked the documentation
and it looks like on windows, you get mpm_winnt, which is different from
even those, though it quite resembles the mpm_worker.

 Since you're using Apache 2.x, mod_jk should be able to
 auto-configure this value for you.

 Do I need to set anything to allow this auto config to happen?

No. If you don't set any value, mod_jk will compute a reasonable (and
usually correct) default. For a prefork MPM, having more than a single
connection in the connection pool is a huge waste, since a single httpd
request processor can't make more than one connection to Tomcat on the
backend. With the worker MPM, the connection pool should probably be the
same size as the number of worker threads you have configured.
Otherwise, you'll have a deficit that may cause the errors you are
encountering.

 From my reading, you may be limiting yourself to 10 simultaneous
 connections from Apache httpd to Tomcat, and others will get a
 503.

 What lead you to that conclusion?

Here's the text from the docs:


This directive has been deprecated since 1.2.16.
Cachesize defines the number of connections made to the AJP backend that
are maintained as a connection pool. It will limit the number of those
connection that each web server child process can make.

Cachesize property is used only for multi threaded web servers such as
Apache 2.0 (worker), IIS and Netscape. The cachesize property should
reflect the number of threads per child process. JK will discover the
number of threads per child process on Apache 2 web server with
worker-mpm and set its default value to match the ThreadsPerChild
Apache directive. [...]


Since mpm_winnt (like mpm_worker) uses ThreadsPerChild to set the number
of worker threads (and therefore simultaneous requests that can be
accepted), you'll have to know what ThreadsPerChild is set to. That's
easy: just search for that directive in httpd.conf. If it's not there,
or commented-out, the default is 64 on mpm_winnt
(http://httpd.apache.org/docs/2.0/mod/mpm_common.html#threadsperchild).

If you've left it as the default (64) and you've set worker.cachesize
(really worker.connection_pool_size) to 10, then you can accept 64
connections from clients but only call-out to Tomcat over 10 of those
connections: the others will have to wait. I'm not sure what the
scheduling algorithm is for choosing which thread gets the next
available connection from the pool (FIFO?), but it's very possible to
starve your clients even after 10 simultaneous connections.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyvKLwACgkQ9CaO5/Lv0PBAqgCgh3/TNdasW5b6cnHXOP99BxrL
jCIAmgMt/kFdRWIut1m9QF8TmzbZ7zW3
=LXSf
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Disable class monitoring for reloading container classes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark,

On 10/8/2010 4:44 AM, Mark Thomas wrote:
 On 08/10/2010 01:11, Jane Muse wrote:
 This happens with both DST and standard time changes. What's interesting
 is if we go back in time to Oct 29 2006, it does not occur. From March
 2007 forward, every fall and spring we get the error when the
 application reloads. The DST time change rules changed in March 2007 for
 USA time zone.
 
 Random thought. Have the necessary timezone updates been applied to the
 OS and to Java? If they are out of sync that could make time appear to
 jump to the JVM.

+1 on the hunch, thought I'm still not sure why Tomcat would perform a
knee-jerk reload unless the initial deployment occurred during the
indeterminate interval between the clock adjustment end points (boy,
this is awkward to discuss).

We had a problem a few years ago in production where Java hadn't been
updated with the new DST rules but the OS had. We try to use NOW() in
our database queries as much as possible, but sometimes it makes much
more sense to just generate a new java.util.Date object for timestamps
and then use those in our SQL queries as well. Due to that incident, we
ended up with records in our database that appeared to have been updated
before they had been created. Oops.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyvKY0ACgkQ9CaO5/Lv0PB5YgCgouMB1Ip2MfM9/eQb+IsNYJ8X
sLcAoK0GzwrD4HKeXP3Vk+pgNKTNHciq
=9eZd
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

disabling session management

2010-10-08 Thread emerson

We been doing some tuning on our TC environment and noticed that
tomcat is holding 30 megabytes of classes related to session
management.

This is on our middletier servler, where sessions are irrelevant.

Is there a way to disabled session management for this server?

What is the impact of using session-timeout = 0?

We currently use 30 minutes for the session-timeout.

Regards
Emerson

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Disable class monitoring for reloading container classes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pid,

On 10/8/2010 4:44 AM, Pid wrote:
 On 08/10/2010 01:19, Jane Muse wrote:
 If I changed the system time zone not to change with daylight savings
 time, then it would be off by an hour. I don't think our customers would
 like that. Or am I misunderstanding your comment?
 
 The system timezone is almost irrelevant, you could use UTC or any other
 stable timezone setting.

+1

 The primitive long value of time inside a Date is the same regardless of
 timezone.  It sounds like you're relying on the system time for date
 display, rather than formatting it as needed when you need to output it.

Yeah, all Date objects ought to be merged with the user's TimeZone to
display the proper locale date/time.

Unfortunately, a java.util.Date object does /not/ carry TimeZone
information with it, but is does depend upon the TimeZone in which it
was created. For example, if your system time zone is America/New_York
(mine), then all your date objects created during DST are essentially
set to (-4 * 60 * 1000) for the timezone offset and (-1 * 60 * 1000) for
the DST offset. If you want to convert that into a different time zone,
you have to compute the difference between the two time zones. This is
one of the reasons it's so advantageous to use UTC for storing dates as
well as your system time zone, since the calculations are much simpler
because one of the zone/DST offsets is always zero.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyvKxwACgkQ9CaO5/Lv0PDzdQCeI2MjoUV0achEE4mD4cgNbLmH
BFUAoIFJKVuSBkA0jWRp5Zl9e9wV8uzl
=Mx7U
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: disabling session management

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Emerson,

On 10/8/2010 10:25 AM, emerson wrote:
 We been doing some tuning on our TC environment and noticed that
 tomcat is holding 30 megabytes of classes related to session
 management.

Which classes, specifically?

 This is on our middletier servler, where sessions are irrelevant.

Okay, great.

 Is there a way to disabled session management for this server?

Don't call request.getSession(). If you have JSPs (in a middle tier?),
make sure they all have session=false in their @page directives.

 What is the impact of using session-timeout = 0?

Your sessions will never time out, and your problem will likely get worse.

 We currently use 30 minutes for the session-timeout.

You could always set it to 1 minute just to be sure they don't last very
long if they are accidentally created.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyvLCgACgkQ9CaO5/Lv0PCOYgCfZTNhOQlUiCkqJ17HAjkOuBqp
AP0Aniew/AE4rFaoKkTwGJGq5uOFRb7P
=iXPl
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: deploy to public_html folder

2010-10-08 Thread William Biggs

there using a os called CloudLinux Server release 5.5 and Apache
Tomcat/5.5.28 and jvm 1.6.0_17-b04
On , Pid wrote:
 On 08/10/2010 00:49, Sreeprasad Govindankutty wrote:
  Upload the .WAR archive to /public_html/servlet
  Extract .WAR archive using Shell access using the unzip command
 
 Unless you have inside knowledge about the OPs environment, that's poor
 advice.
 
  On Thu, Oct 7, 2010 at 6:54 PM, William Biggs kc8...@gmail.com wrote:
  
  I would like to know how to deploy a war to the public_html ?
 
 Did you ask this question recently?
 
 Apache Tomcat != Apache HTTPD
 
 The methods for deploying sites are very different.
 
 Please provide the following information: what are the exact Tomcat, JVM
 and OS versions you are using?
 
 
 p
 



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Disable class monitoring for reloading container classes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pid,

On 10/7/2010 5:52 PM, Pid wrote:
 On 07/10/2010 22:30, Christopher Schultz wrote:

 If the above logic is the actual implementation, then the only time
 you'd have a problem is when you've deployed a webapp during the window
 covered by the DST-clock-setback. For instance, if the clock goes from
 02:00 early Sunday morning to 00:00 early Sunday morning, then you
 should only experience some kind of confusion if you deploy between
 00:00 and 02:00 the first time through early on Sunday morning.
 
 +1 actually. Logical.

I browsed the code and it looks like the reload-check is done in the
WebappClassLoader.modified() method which you can find in here for
Jane's specific version:

http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_18/java/org/apache/catalina/loader/WebappClassLoader.java

Technically speaking, the modification date isn't checked against the
context startup date it's checked against the last modified date
that was recorded by the ClassLoader. That makes sense because you might
have a JAR file that's been updated but the timestamp is still in the past.

In either case, this seems weird.

Jane, if you increase your logging level to DEBUG, you should be able to
see the modified() method being called, and it should tell you what
resource is triggering the reload in the webapp's log file.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyvM54ACgkQ9CaO5/Lv0PA6rACfUghfrik2nmW9n7usJZhUMKbZ
W9UAnA82HPzCB8rcJTsi8hpou7kzeu/Z
=kvUe
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

jsvc takes a really long time to start tomcat

2010-10-08 Thread Mark Shifman

jsvc used to stop and start my tomcat server very quickly (15-30 seconds).

Recently, I noticed it stops right away but takes about 3 minutes to start.
(I of course don't know what I changed.)
I have tried: 1.recompiling jsvc, 2.using the newest native 
commons-daemon-1.0.3-bin-linux-x86_64.tar.gz
and commons daemon commons-daemon-1.0.3-bin.tar.gz
with no improvement.

I must be missing something very basic.
Any help would be appreciated.
mas

System details:
tomcat 6.0.18
java version 1.6.0_20
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
CentOS release 5.2 (Final)
Linux  2.6.18-92.1.22.el5 #1 SMP Tue Dec 16 11:57:43 EST 2008 x86_64 x86_64 
x86_64 GNU/Linux

the start up script:

# Source function library.
. /etc/init.d/functions

# Adapt the following lines to your configuration
JAVA_HOME=/usr/java/jdk1.6.0_20
CATALINA_HOME=/home/apache-tomcat-6.0.18
DAEMON_HOME=/home/apache-tomcat-6.0.18/bin
TOMCAT_USER=tomcat

CATALINA_OPTS= -Djava.awt.headless=true -Xmx1g -Xms1g -Xincgc 
-XX:MaxPermSize=256m 
CLASSPATH=\
$JAVA_HOME/lib/tools.jar:\
$CATALINA_HOME/bin/commons-daemon.jar:\
$CATALINA_HOME/bin/bootstrap.jar

start(){
$DAEMON_HOME/jsvc \
-user $TOMCAT_USER \
-home $JAVA_HOME \
-Dcatalina.home=$CATALINA_HOME \
-Djava.io.tmpdir=$CATALINA_HOME/temp \
-outfile $CATALINA_HOME/logs/catalina.out \
-errfile '1' \
$CATALINA_OPTS \
-cp $CLASSPATH \
org.apache.catalina.startup.Bootstrap
echo starting:  $CATALINA_HOME
echo tomcat user:  $TOMCAT_USER

}

stop(){
$DAEMON_HOME/jsvc \
-stop \
-pidfile  /var/run/jsvc.pid \
org.apache.catalina.startup.Bootstrap

echo stopping tomcat:  $CATALINA_HOME
echo tomcat user:  $TOMCAT_USER

}


case $1 in
  start)
#
# Start Tomcat
#
start
;;

  status)
status jsvc
;;

  stop)
#
# Stop Tomcat
#
stop
;;

  restart)
stop
start
;;

  *)
echo Usage tomcat6.0.18  start/stop/restart/status
exit 1;;
esac

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] apache-tomcat-6.0.29 will not start with more then 1024mb memory assigned - windows

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 10/8/2010 8:32 AM, André Warnier wrote:
 Hans Magne Helland wrote:
 But now it uses a lot of CPU. Googled it, and saw people having
 CPU-usage issues with ESX Vmware and Tomcat. Is this a known thing?

 As a bit of an outsider, I'd tell you that the CPU and RAM usage are a
 known thing, not particularly with Vmware or Tomcat, but with anything
 Java.
 The switch to 64-bit merely seems to double it.
 
 But the guys on this list are all Java freaks, so they would probably
 not understand what we're talking about.  Or else they do, and they all
 have shares in Intel and Kingston.
 :-)

Let's be fair: we're Java fanboys, not Java freaks ;)

Switching to 64-bit will double the size of your pointers regardless of
programming language. Actually, Java can compress pointers even under a
64-bit environment to save space, so in that way, it might not balloon
memory use. :p

In my experience, Java does not use significantly more CPU than programs
of similar (and reasonable) complexity written in other languages: the
problem is that most people compare apples to oranges. They will compare
a Hello World program in Java and C and show you that the Java program
requires 6MB of heap just to get going and takes have a second to run
while the C program requires no heap whatsoever and runs instantaneously.

Yes, that's true. However, Java wasn't built to run trivial things like
Hello World. Once you get into significant complexity, the playing
field levels quite dramatically. That's why, when writing programs, I
choose the technology that is appropriate for the situation instead of
running to one or another language/environment all the time. For
production operations, we use Java for all of our web apps, but we have
lots of utilities written in Perl, PHP, Bash scripts, and the occasional
C program: the right tool for the right job IMHO.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyvOdMACgkQ9CaO5/Lv0PAfdQCffhIakLmPycvlseZ2Y28B58vM
cjkAnRzv6M+sCbZzxrqmGChF255GZFNY
=2z2f
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: jsvc takes a really long time to start tomcat

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark,

On 10/8/2010 11:30 AM, Mark Shifman wrote:
 jsvc used to stop and start my tomcat server very quickly (15-30 seconds).
 
 Recently, I noticed it stops right away but takes about 3 minutes to start.
 (I of course don't know what I changed.)

Often this kind of long startup time is due to one of the following
problems:

1. Misconfigured DNS which takes a long time to timeout during a lookup

Solution: fix your DNS

2. Use of blocking source of entropy for PRNGs

Solution: use /dev/urandom (or equivalent) instead of /dev/random (or
equivalent) in your JRE's lib/security/java.security file. The setting
you want to confirm is securerandom.source. Most recent Sun JRE
releases use /dev/urandom if it is available.

If you are using OpenSSL via the tc-native library (aka APR), you
might want to check to see how that's been configured wrt random sources.

If you run Tomcat directly (not through jsvc) does it start up faster?
My guess is that jsvc is /not/ the problem here. If Tomcat itself starts
up slowly, try taking a thread dump during the long pause before
startup: it'll likely reveal the source of the problem.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyvO1sACgkQ9CaO5/Lv0PDjRQCeLMn3ceU4uhS8cdCb2IfjPYJT
D6MAn0I853Igv+5dSUxq+j2fsSZ7/7yw
=iW5O
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Disable class monitoring for reloading container classes

Christopher Schultz wrote:
...

Technically speaking, the modification date isn't checked against the
context startup date it's checked against the last modified date
that was recorded by the ClassLoader. That makes sense because you might
have a JAR file that's been updated but the timestamp is still in the past.

In either case, this seems weird.

Yes, to me too, when compared to what Jane mentioned earlier, and which I
commented :

This happens with both DST and standard time changes. What's interesting
is if we go back in time to Oct 29 2006, it does not occur. From March
2007 forward, every fall and spring we get the error when the
application reloads. The DST time change rules changed in March 2007 for
USA time zone.

I get this uneasy feeling about this, but I agree with Christopher that it's easy to get
confused, and uneasy to describe.

Let's do this graphically. Below is a timeline. 0 is when Tomcat starts, and
(supposedly) the base reference time for this application.
A ! symbol marks when Tomcat checks if a file has been modified. A x symbol marks
when a file /has/ been modified.

0 1 2 3 4 5
!--!--!x-!--!x-! ... (you get the idea)

At time t1, nothing has changed, and nothing happens.
At time t2, nothing has changed, and nothing happens.
At time t2.5, the application's files are modified.
At time t3, Tomcat (presumably), notes that the last modify time of the files (t2.5) is
now later than the application's last reloaded stamp (t0); so it reloads the
application, and marks it as reloaded at time t3.
At time t4, the application's files last modified time still shows t2.5, and the
application's last reloaded time shows t3. Since reloaded is after modified, it's
OK, and no reload is necessary.

At time t4.5, the files are modified again.
At time t5, Tomcat (presumably), notes that the last modify time of the files (t4.5) is
now higher/later than the application's last reloaded stamp (t3); so it reloads the
application, and marks it as reloaded at time t5.

Now let's imagine the same thing, but at time t4, the system time is reset to
t2.
The last reloaded time of the application remains at t3 (it is in memory somewhere, and
is unaffected by the OS time change).
In the filesystem, the files last modified timestamp remains at t2.5 (it is also
unaffected by the time change of the OS).
Tomcat moves on, and at the (new) time t3, it finds that the last reload is marked t3
but the files last modified stamp is t2.5.
t3 t2.5, so it should not reload, but that may depend on how exactly the calculation
happens. If the calculation involves the current system time, then there may be a
sneaky bug there.

Now instead, let's suppose that at time t3, the system time is reset to t1.
Tomcat moves on, and at the new time t2, it finds that the files were modified at time
t2.5 (in the future), but the last reloaded stamp of the application is t3 (further in
the future). Since t3 t2.5, it should not reload. But again, some sneaky bug in the
calculation may..

But can we get a case where the last modified timestamp of the files would /falsely/ be
higher than the last reloaded time of the application ?

I think so :
Say that the system time is reset at t2.999, to t0.999. At the new t1, Tomcat
checks.
It then finds the last modified stamp at t2.5, and the last reloaded stamp
at t0.
So it reloads the application, and marks it as reloaded at t1 (now, from the OS point
of view).
It is right to reload, because the application has really been modified since it was last
loaded. (But this may just be luck).
But now Tomcat moves on and reaches the new t2. It finds the files last modified stamp
at t2.5 (they have not changed), and the last reloaded at t1. So it (wrongly) reloads
the application again, and marks it as reloaded at t2.
And it will do it again at t3, because then the application's files will still have the
t2.5 timestamp, and the last reloaded would be t2.

Just a scenario of course.
I have not realy worked out what the effect is, if Tomcat is in a 5 seconds sleep, and the
system time is reset during those 5 seconds.
Neither is there any particular reason why the system time (visualised above by the t0,
t1, t2,..) should be synchronised with when Tomcat checks.
I believe the whole thing hangs onto which source of time Tomcat uses to take the last
reloaded time, and the source of time used by the filesystem when a file is modified
(which is always the current OS time, and has nothing to do with Tomcat).

I may have made some fundamental mistake in the above, and have been writing
nonsense.
Or maybe I found a terrible bug in Tomcat, which would otherwise cause the next global
financial crisis (and might have caused the last one).

Selfishly, I would prefer the latter. But either way, it was fun.

And it still does not explain why an application would be reloaded in the absence

Tomcat 5.5.25 | Memory leak in Web Application

2010-10-08 Thread Anurag Kapur

*Problem Statement*

Memory leak in web application running on Tomcat

*System Information*

Tomcat 5.5.27

Apache HTTPD 2.2.9

Java HotSpot(TM) Server VM (build 1.5.0_14-b03, mixed mode)

Mod_proxy_http connector

Solaris 10 x86

Tomcat JVM heap settings: min:2GB and max:2GB

*Observations and Investigation Done*

Under load, the web application slowly runs out of heap space. The heap
utilization graph suggests a memory leak type pattern.

Heap dumps were gathered to determine the root cause and observations are as
below from the dumps:

1. HashMap entries from the below object reference tree seem to consume
over 80% of the used tenured generation space.

org/apache/jasper/compiler/JspRuntimeContext

↓

Java/util/Collections$SynchronizedMap

↓

Java/util/HashMap

↓

Java/util/HashMap$Entry

1. Heap dumps gathered during different times and after a Full GC always
indicate 100 entries
2. The number of objects referenced by each HashMap entry vary between
2-3
1. These are either a String and JspServletWrapper object

1. A String, JspServletWrapper and *another HashMap Entry*. This call
reference tree of HashMap entries referenced by another HashMap entry can
repeat to a depth of approximately 8-10 nodes

The above is indicated in an object reference tree obtained after analyzing
the Heap dump as shown below

1. The maximum percentage of the memory occupied by the HashMap entry
object is by a character array that seems like the JSP servlet response.
HTML response (tags with content) can be seen in the character array

*Questions*

1. I am stuck at this point and have run out of ideas on how to get to
the root cause of this issue. Do you have any ideas/suggestions to help
identify the root cause?
2. I google and found the following interesting links
1. http://www.mail-archive.com/d...@tomcat.apache.org/msg03395.html Is
there any know issues, configuration that causes a memory leak
by caching of
servlet responses in the container and not flushing the cached objects?
2.

http://mail-archives.apache.org/mod_mbox/tomcat-users/200303.mbox/%3c000c01c2ee2c$41c079a0$03b69...@garethdqw0t9if%3ewe
use a lot of JSTL in our web application. Are there any known issues
around memory issues as indicated on the link?

Any inputs to help identify the root cause of this problem would be highly
appreciated.

Kind Regards

Anurag

---
Anurag Kapur

Senior Associate - Technology,
Sapient Corporation.

http://www.linkedin.com/in/anuragkapur

http://www.google.com/profiles/anuragkapur
---

JDBC Leak Prevention and Security Manager

2010-10-08 Thread George Sexton

I'm running Tomcat 6.0.29 with the security manager enabled. I'm getting
these entries in my log:

2010-10-07 12:09:01,710 WARN http-80-76
org.apache.catalina.loader.WebappClassLoader - JDBC driver de-registration
failed for web application []
 java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.catalina.loader.WebappClassLoader.clearReferencesJdbc(WebappClass
Loader.java:1960)
at
org.apache.catalina.loader.WebappClassLoader.clearReferences(WebappClassLoad
er.java:1880)
.
Caused by: java.security.AccessControlException: access denied
(java.lang.RuntimePermission getClassLoader)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java
:323)
at
java.security.AccessController.checkPermission(AccessController.java:546)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.Class.getClassLoader(Class.java:594)
at
org.apache.catalina.loader.JdbcLeakPrevention.clearJdbcDriverRegistrations(J
dbcLeakPrevention.java:49)
... 44 more

Could any give me a hint as to what I need to add to the catalina.policy
file to make this work?

Should I file this as a bug?

George Sexton
MH Software, Inc.
303 438-9585
www.mhsoftware.com




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JDBC Leak Prevention and Security Manager

2010-10-08 Thread Mark Thomas

On 08/10/2010 21:20, George Sexton wrote:
 Could any give me a hint as to what I need to add to the catalina.policy
 file to make this work?
 
 Should I file this as a bug?

https://issues.apache.org/bugzilla/show_bug.cgi?id=49209

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Disable class monitoring for reloading container classes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 10/8/2010 2:12 PM, André Warnier wrote:
 0  1  2  3  4  5
 !--!--!x-!--!x-! ... (you get
 the idea)
 
 At time t1, nothing has changed, and nothing happens.
 At time t2, nothing has changed, and nothing happens.
 At time t2.5, the application's files are modified.
 At time t3, Tomcat (presumably), notes that the last modify time of
 the files (t2.5) is now later than the application's last reloaded
 stamp (t0); so it reloads the application, and marks it as reloaded at
 time t3.

Technically speaking, all the files' timestamps are recorded at t0 and
compared at tX to their t0 timestamps. When the application is
re-loaded, presumably everything is re-scanned and you basically have a
new t0 situation.

 Now let's imagine the same thing, but at time t4, the system time is
 reset to t2.

Here's where my above comment comes into play: the current time has /no
bearing on anything/, since the file timestamps are always compared to
their previous values. Tomcat doesn't care about when the webapp was
last loaded: it only cares about the previously-recorded file timestamp
for each file. When tX != t0, a reload is triggered.

If I read the code correctly, this means that even if the webapp is
intentionally initialized during a clock-setback, it shouldn't reload
when the clock actually gets set back.

 But can we get a case where the last modified timestamp of the files
 would /falsely/ be higher than the last reloaded time of the
 application ?

Since Tomcat simply does a != check rather than  or , I think that
none of this should ever happen.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyvhXcACgkQ9CaO5/Lv0PCwNwCfQf9aQJeiXUM2W4LgQj3Rvn/0
kogAoLFnXuNe8gUWBzzDYWB79A55mkBf
=+cEv
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 5.5.25 | Memory leak in Web Application

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Anurag,

On 10/8/2010 3:15 PM, Anurag Kapur wrote:
 _Problem Statement_
 Memory leak in web application running on Tomcat

_Solution Statement_

Fix your memory leak

 _System Information_
 
 Tomcat 5.5.27

This statement plus the subject line are confusing me.

 _Observations and Investigation Done_
 
 Under load, the web application slowly runs out of heap space. The heap
 utilization graph suggests a memory leak type pattern.

Attachments are stripped: there is no image to view, here.

 Heap dumps were gathered to determine the root cause and observations
 are as below from the dumps:
 
1. HashMap entries from the below object reference tree seem to
   consume over 80% of the used tenured generation space.
 
 org/apache/jasper/compiler/JspRuntimeContext
 Java/util/Collections$SynchronizedMap
 Java/util/HashMap
 Java/util/HashMap$Entry

If this doesn't grow, then it doesn't sound like a memory leak.

2. Heap dumps gathered during different times and after a Full GC
   always indicate 100 entries

This indicates zero growth, so I would guess no memory leak.

3. The number of objects referenced by each HashMap entry vary
   between 2-3
  1. These are either a String and JspServletWrapper object
 
 or
 
  2. A String, JspServletWrapper and _another HashMap Entry_.
 This call reference tree of HashMap entries referenced by
 another HashMap entry can repeat to a depth of approximately
 8-10 nodes

That sounds weird.

 The above is indicated in an object reference tree obtained after
 analyzing the Heap dump as shown below
 
4. The maximum percentage of the memory occupied by the HashMap entry
   object is by a character array that seems like the JSP servlet
   response. HTML response (tags with content) can be seen in the
   character array

Does this response text stay in memory indefinitely? When you say it's
the response, is it the actual response to a particular client, or is it
just static text from the JSP source? If the latter, this is completely
expected: the JSP compiles-in all static text.

 _Questions_
 
1. I am stuck at this point and have run out of ideas on how to get
   to the root cause of this issue. Do you have any ideas/suggestions
   to help identify the root cause?

Finding the roots to those references should help. For instance, what
page is holding on to all those entries? It's possible that the
JSPRuntimeContext requires these data even after the compiler has
compiled the code.

2. I google and found the following interesting links
  1. http://www.mail-archive.com/d...@tomcat.apache.org/msg03395.html
 Is there any know issues, configuration that causes a memory
 leak by caching of servlet responses in the container and
 not flushing the cached objects?

The above seems to be a complaint about how JSPs work: they are
translated into .java files, then compiled and loaded. These loaded
class files contain lots of static strings. There's nothing to be done
about this.

  2. 
 http://mail-archives.apache.org/mod_mbox/tomcat-users/200303.mbox/%3c000c01c2ee2c$41c079a0$03b69...@garethdqw0t9if%3e
 We use a lot of JSTL in our web application. Are there any
 known issues around memory issues as indicated on the link?

This one is seriously old: 2003 was a long time ago (even older than
your version of Tomcat). I don't think that post is relevant anymore.

You should consider upgrading. Check the changelog
(http://tomcat.apache.org/tomcat-5.5-doc/changelog.html) for changes to
Jasper between your version (5.5.25 or 5.5.27) and the latest (5.5.30).
You also might consider upgrading to Tomcat 6.0.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyviC8ACgkQ9CaO5/Lv0PCHQQCeKH/X4Ee4nN1Z3x19wCNkWW3Q
pf0An2e+6trJtZezARIhx3GXifLUVpWc
=Id6K
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Disable class monitoring for reloading container classes


Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 10/8/2010 2:12 PM, André Warnier wrote:

0  1  2  3  4  5
!--!--!x-!--!x-! ... (you get
the idea)

At time t1, nothing has changed, and nothing happens.
At time t2, nothing has changed, and nothing happens.
At time t2.5, the application's files are modified.
At time t3, Tomcat (presumably), notes that the last modify time of
the files (t2.5) is now later than the application's last reloaded
stamp (t0); so it reloads the application, and marks it as reloaded at
time t3.


Technically speaking, all the files' timestamps are recorded at t0 and
compared at tX to their t0 timestamps. When the application is
re-loaded, presumably everything is re-scanned and you basically have a
new t0 situation.


Now let's imagine the same thing, but at time t4, the system time is
reset to t2.


Here's where my above comment comes into play: the current time has /no
bearing on anything/, since the file timestamps are always compared to
their previous values. Tomcat doesn't care about when the webapp was
last loaded: it only cares about the previously-recorded file timestamp
for each file. When tX != t0, a reload is triggered.

If I read the code correctly, this means that even if the webapp is
intentionally initialized during a clock-setback, it shouldn't reload
when the clock actually gets set back.


But can we get a case where the last modified timestamp of the files
would /falsely/ be higher than the last reloaded time of the
application ?


Since Tomcat simply does a != check rather than  or , I think that
none of this should ever happen.



Thanks for checking the code.

In that case,
- Jane's experience is still incomprehensible
- the possible bug I mentioned cannot happen
- but the logic used by Tomcat seems wasteful : aren't these a lot of files for which 
Tomcat needs to keep a timestamp ?

But maybe it was done that way /precisely/ to avoid the issue I mentioned.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Disable class monitoring for reloading container classes

2010-10-08 Thread Jeffrey Janner

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Friday, October 08, 2010 3:56 PM
 To: Tomcat Users List
 Subject: Re: Disable class monitoring for reloading container classes

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 André,

 On 10/8/2010 2:12 PM, André Warnier wrote:
  0  1  2  3  4  5
  !--!--!x-!--!x-! ... (you get
  the idea)

  At time t1, nothing has changed, and nothing happens.
  At time t2, nothing has changed, and nothing happens.
  At time t2.5, the application's files are modified.
  At time t3, Tomcat (presumably), notes that the last modify time of
  the files (t2.5) is now later than the application's last reloaded
  stamp (t0); so it reloads the application, and marks it as reloaded
 at
  time t3.

 Technically speaking, all the files' timestamps are recorded at t0 and
 compared at tX to their t0 timestamps. When the application is
 re-loaded, presumably everything is re-scanned and you basically have a
 new t0 situation.

  Now let's imagine the same thing, but at time t4, the system time is
  reset to t2.

 Here's where my above comment comes into play: the current time has /no
 bearing on anything/, since the file timestamps are always compared to
 their previous values. Tomcat doesn't care about when the webapp was
 last loaded: it only cares about the previously-recorded file timestamp
 for each file. When tX != t0, a reload is triggered.

 If I read the code correctly, this means that even if the webapp is
 intentionally initialized during a clock-setback, it shouldn't reload
 when the clock actually gets set back.

  But can we get a case where the last modified timestamp of the
 files
  would /falsely/ be higher than the last reloaded time of the
  application ?

 Since Tomcat simply does a != check rather than  or , I think that
 none of this should ever happen.

 - -chris

Then according to Jane's description, something is changing the read value of 
the files' timestamps, as far as Tomcat is concerned.  That is the only 
explanation for what she is seeing.
So, Tomcat records the current timestamp for file X as 2010-02-02.11:55:00 on 
startup.  At 2:00am on the first Sunday, the DST kicks in and the next time 
Tomcat requests file X's timestamp, it gets back the date with conversion 
applied using the new DST value, so the value is now 1 hour off (+/-), thus the 
reload.  
In other words, raw timestamp is not being used, as it should.  Could be O/S or 
Java returning a converted timestamp, or something in how TC is processing the 
stored time?
I seriously doubt this explanation, but it seems the only one to fit.  
Particularly if Jane is absolutely sure no files are being modified at the 
time.  A timestamp is a timestamp, and should return the same time value for a 
particular date/time no matter if you are before or after the DST change.  
(Possible exception for that spring jump when you have repeated times. That is 
why no changes should be planned for that 2-hour period.  The fall one isn't so 
bad, since an hour just goes missing. God I really hate DST. Don't let me get 
started on a rant.)
__

Confidentiality Notice:  This Transmission (including any attachments) may 
contain information that is privileged, confidential, and exempt from 
disclosure under applicable law.  If the reader of this message is not the 
intended recipient you are hereby notified that any dissemination, 
distribution, or copying of this communication is strictly prohibited.  

If you have received this transmission in error, please immediately reply to 
the sender or telephone (512) 343-9100 and delete this transmission from your 
system.

Re: [OT] Disable class monitoring for reloading container classes


Jeffrey Janner wrote:
..
 God I really hate DST. Don't let me get started on a rant.)
..
Right. As someone once asked me : Why could they not leave the time as God gave us, 
he ?


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 5.5.25 | Memory leak in Web Application

2010-10-08 Thread Anurag Kapur

Thanks for your response Chris.

On Fri, Oct 8, 2010 at 10:07 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Anurag,

 On 10/8/2010 3:15 PM, Anurag Kapur wrote:
  _Problem Statement_
  Memory leak in web application running on Tomcat

 _Solution Statement_

 Fix your memory leak


That's the plan :)


  _System Information_
 
  Tomcat 5.5.27

 This statement plus the subject line are confusing me.


Apologies. I have made a typo in the subject line. I am using Tomcat 5.5.27

 _Observations and Investigation Done_
 
  Under load, the web application slowly runs out of heap space. The heap
  utilization graph suggests a memory leak type pattern.

 Attachments are stripped: there is no image to view, here.


I have attached the heap usage graph as a file this time (heap_usage.jpg)



 Heap dumps were gathered to determine the root cause and observations
  are as below from the dumps:
 
 1. HashMap entries from the below object reference tree seem to
consume over 80% of the used tenured generation space.
 
  org/apache/jasper/compiler/JspRuntimeContext
  Java/util/Collections$SynchronizedMap
  Java/util/HashMap
  Java/util/HashMap$Entry

 If this doesn't grow, then it doesn't sound like a memory leak.


The number of entries under the HashMap referenced by JspRuntimeContent -
 Collections$SynchronizedMap does not increase. However the size of these
100 entries increases with time. In my last test, after the first full GC
the size of this HashMap was around 350MB. With time and under load, this
increased. Next heap dump gathered after the 4th Full GC showed that the
size of this hash map had doubled to around 730MB. The number of entries
immediately under this HashMap however remained constant.



 2. Heap dumps gathered during different times and after a Full GC
always indicate 100 entries

 This indicates zero growth, so I would guess no memory leak.


Yes, the number of immediate entries in the Hashmap remained constant
however the size these occupy in the heap increased.



 3. The number of objects referenced by each HashMap entry vary
between 2-3
   1. These are either a String and JspServletWrapper object
 
  or
 
   2. A String, JspServletWrapper and _another HashMap Entry_.
  This call reference tree of HashMap entries referenced by
  another HashMap entry can repeat to a depth of approximately
  8-10 nodes

 That sounds weird.


To make this a little clear, I have attached a screen shot of the object
reference tree from IBM Heap analyzer I used on the heap dumps obtained.
(object_reference_tree.jpg)



  The above is indicated in an object reference tree obtained after
  analyzing the Heap dump as shown below
 
 4. The maximum percentage of the memory occupied by the HashMap entry
object is by a character array that seems like the JSP servlet
response. HTML response (tags with content) can be seen in the
character array

 Does this response text stay in memory indefinitely? When you say it's
 the response, is it the actual response to a particular client, or is it
 just static text from the JSP source? If the latter, this is completely
 expected: the JSP compiles-in all static text


I am having difficulties at this stage determining this with 100%
confidence. I am mostly seeing static HTML tags in the character array that
would be coming from the static JSP source. However I have also seen some
references to dynamic content that is sent back to the client in these
charcter arrays. There is atleast 1 such character array in each of these
100 has map entries. Sometime more in cases where there are more hash map
entries within an entry. I have not seen the size of all these charcter
arrays but a few are as big as 7MB.

.

  _Questions_
 
 1. I am stuck at this point and have run out of ideas on how to get
to the root cause of this issue. Do you have any ideas/suggestions
to help identify the root cause?

 Finding the roots to those references should help. For instance, what
 page is holding on to all those entries? It's possible that the
 JSPRuntimeContext requires these data even after the compiler has
 compiled the code.


I can also see the name of the custom JSP files in the object call reference
trees under most of these 100 hash map entries. However some of them are
relatively simple and I am unable to think of a reason why such a JSP would
hold reference in the heap causing the leak. As you suggested, I am now
trying to search for objects I see in the heap dump obtained after the first
Full GC in the dump obtained after the 4th Full GC.

Thanks for your inputs so far. Any other inputs while I do the investigation
highlighted above?

2. I google and found the following interesting links
   1.
 http://www.mail-archive.com/d...@tomcat.apache.org/msg03395.html
  Is there any

Re: Tomcat 5.5.25 | Memory leak in Web Application

2010-10-08 Thread Anurag Kapur

On Fri, Oct 8, 2010 at 11:04 PM, Anurag Kapur anuragka...@gmail.com wrote:

 Thanks for your response Chris.

 On Fri, Oct 8, 2010 at 10:07 PM, Christopher Schultz 
 ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Anurag,

 On 10/8/2010 3:15 PM, Anurag Kapur wrote:
  _Problem Statement_
  Memory leak in web application running on Tomcat

 _Solution Statement_

 Fix your memory leak


 That's the plan :)


  _System Information_
 
  Tomcat 5.5.27

 This statement plus the subject line are confusing me.


 Apologies. I have made a typo in the subject line. I am using Tomcat 5.5.27

  _Observations and Investigation Done_
 
  Under load, the web application slowly runs out of heap space. The heap
  utilization graph suggests a memory leak type pattern.

 Attachments are stripped: there is no image to view, here.


 I have attached the heap usage graph as a file this time (heap_usage.jpg)



  Heap dumps were gathered to determine the root cause and observations
  are as below from the dumps:
 
 1. HashMap entries from the below object reference tree seem to
consume over 80% of the used tenured generation space.
 
  org/apache/jasper/compiler/JspRuntimeContext
  Java/util/Collections$SynchronizedMap
  Java/util/HashMap
  Java/util/HashMap$Entry

 If this doesn't grow, then it doesn't sound like a memory leak.


 The number of entries under the HashMap referenced by JspRuntimeContent -
  Collections$SynchronizedMap does not increase. However the size of these
 100 entries increases with time. In my last test, after the first full GC
 the size of this HashMap was around 350MB. With time and under load, this
 increased. Next heap dump gathered after the 4th Full GC showed that the
 size of this hash map had doubled to around 730MB. The number of entries
 immediately under this HashMap however remained constant.



 2. Heap dumps gathered during different times and after a Full GC
always indicate 100 entries

 This indicates zero growth, so I would guess no memory leak.


 Yes, the number of immediate entries in the Hashmap remained constant
 however the size these occupy in the heap increased.



 3. The number of objects referenced by each HashMap entry vary
between 2-3
   1. These are either a String and JspServletWrapper object
 
  or
 
   2. A String, JspServletWrapper and _another HashMap Entry_.
  This call reference tree of HashMap entries referenced by
  another HashMap entry can repeat to a depth of approximately
  8-10 nodes

 That sounds weird.


 To make this a little clear, I have attached a screen shot of the object
 reference tree from IBM Heap analyzer I used on the heap dumps obtained.
 (object_reference_tree.jpg)



  The above is indicated in an object reference tree obtained after
  analyzing the Heap dump as shown below
 
 4. The maximum percentage of the memory occupied by the HashMap entry
object is by a character array that seems like the JSP servlet
response. HTML response (tags with content) can be seen in the
character array

 Does this response text stay in memory indefinitely? When you say it's
 the response, is it the actual response to a particular client, or is it
 just static text from the JSP source? If the latter, this is completely
 expected: the JSP compiles-in all static text


 I am having difficulties at this stage determining this with 100%
 confidence. I am mostly seeing static HTML tags in the character array that
 would be coming from the static JSP source. However I have also seen some
 references to dynamic content that is sent back to the client in these
 charcter arrays. There is atleast 1 such character array in each of these
 100 has map entries. Sometime more in cases where there are more hash map
 entries within an entry. I have not seen the size of all these charcter
 arrays but a few are as big as 7MB.

 .

  _Questions_
 
 1. I am stuck at this point and have run out of ideas on how to get
to the root cause of this issue. Do you have any ideas/suggestions
to help identify the root cause?

 Finding the roots to those references should help. For instance, what
 page is holding on to all those entries? It's possible that the
 JSPRuntimeContext requires these data even after the compiler has
 compiled the code.


 I can also see the name of the custom JSP files in the object call
 reference trees under most of these 100 hash map entries. However some of
 them are relatively simple and I am unable to think of a reason why such a
 JSP would hold reference in the heap causing the leak. As you suggested, I
 am now trying to search for objects I see in the heap dump obtained after
 the first Full GC in the dump obtained after the 4th Full GC.


I did a quick check on the heap dumps. I noted the address of the character
array referenced by the largest entry in the hash map from the first dump. I

RE: Tomcat 5.5.25 | Memory leak in Web Application

2010-10-08 Thread Caldarale, Charles R

 From: Anurag Kapur [mailto:anuragka...@gmail.com] 
 Subject: Re: Tomcat 5.5.25 | Memory leak in Web Application

  Attachments are stripped: there is no image to view, here.

 I have attached the heap usage graph as a file this time (heap_usage.jpg)

Please read Chris' statement again: attachments are stripped.  If you want us 
to look at the pictures, you'll have to post them in some public location on 
the web.

 Or can the address of the object change in the 
 lifetime of the tomcat jvm?

An object can move on each GC.

 - 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: Disable class monitoring for reloading container classes

2010-10-08 Thread Jane Muse

 
Chris wrote:

Jane, if you increase your logging level to DEBUG, you should be able
to see the modified() method being called, and it should tell you what
resource is triggering the reload in the webapp's log file.

I set the system date to: 11/07/10 at 1:53:00 and started tomcat. At
2:00 the time changes to 01:00, and the following statements in the log
show the resource that was modified:

DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]]
org.apache.catalina.loader.WebappClassLoader - modified()
DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]]
org.apache.catalina.loader.WebappClassLoader - modified()
DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]]
org.apache.catalina.loader.WebappClassLoader -   Resource
'/WEB-INF/lib/ant-1.6.5.jar' was modified; Date is now: Sun Aug 22
19:51:04 PDT 2010 Was: Sun Aug 22 18:51:04 PDT 2010
INFO ContainerBackgroundProcessor[StandardEngine[Catalina]]
org.apache.catalina.core.StandardContext - Reloading this Context has
started
DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]]
org.apache.catalina.loader.WebappClassLoader -
loadClass(org.apache.struts.action.RequestProcessor, false)

When the time fell back 1 hour, the modified time for ant-1.6.5.jar also
showed as changed to 1 hour prior to previous timestamp, and that
prompted the reload.

I have reloading=false and autoDeploy=false set in the context.xml
and server.xml.

Does this look like a tomcat bug, if so are you aware if it's been fixed
in a later version (I'm at 6.0.18)?

Many thanks,

Jane



-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Friday, October 08, 2010 8:07 AM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pid,

On 10/7/2010 5:52 PM, Pid wrote:
 On 07/10/2010 22:30, Christopher Schultz wrote:

 If the above logic is the actual implementation, then the only time 
 you'd have a problem is when you've deployed a webapp during the 
 window covered by the DST-clock-setback. For instance, if the clock 
 goes from 02:00 early Sunday morning to 00:00 early Sunday morning, 
 then you should only experience some kind of confusion if you deploy 
 between 00:00 and 02:00 the first time through early on Sunday
morning.
 
 +1 actually. Logical.

I browsed the code and it looks like the reload-check is done in the
WebappClassLoader.modified() method which you can find in here for
Jane's specific version:

http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_18/java/o
rg/apache/catalina/loader/WebappClassLoader.java

Technically speaking, the modification date isn't checked against the
context startup date it's checked against the last modified date
that was recorded by the ClassLoader. That makes sense because you might
have a JAR file that's been updated but the timestamp is still in the
past.

In either case, this seems weird.

Jane, if you increase your logging level to DEBUG, you should be able to
see the modified() method being called, and it should tell you what
resource is triggering the reload in the webapp's log file.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyvM54ACgkQ9CaO5/Lv0PA6rACfUghfrik2nmW9n7usJZhUMKbZ
W9UAnA82HPzCB8rcJTsi8hpou7kzeu/Z
=kvUe
-END PGP SIGNATURE-

-
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

Re: Disable class monitoring for reloading container classes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 10/8/2010 5:20 PM, André Warnier wrote:
 In that case,
 - Jane's experience is still incomprehensible
 - the possible bug I mentioned cannot happen

+1 +1

 - but the logic used by Tomcat seems wasteful : aren't these a lot of
 files for which Tomcat needs to keep a timestamp ?

Did you mean aren't /there/ a lot of files...? Yes, there are a lot of
files to keep track of, but it really depends on the webapp. It will
store the timestamps for all .jar files in the WEB-INF/lib directory,
any .class file in WEB-INF/classes, plus anything you've added under a
WatchedResource.

 But maybe it was done that way /precisely/ to avoid the issue I mentioned.

Maybe just a happy accident :)

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyvwS0ACgkQ9CaO5/Lv0PAkQwCffLzQ4zpeWKnKNqCNCvEqpvmn
vkAAoJnw4wMGjYVCu1u/BWGxDjB9lfEW
=/DlI
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Disable class monitoring for reloading container classes