Re: disabling session management

2010-10-13 Thread Michael Echerer
Hi,

you could also use a SessionListener an invalidate sessions immediately
after being created or you could write your own implementation of
|org.apache.catalina.Manager
|http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html and
configure it to be used instead of the default manager.
Can't be too difficult if jit ust has to serve as a NOP
implementation... However I would prefer to figure out why sessions are
unexpectedly created at all.

Cheers,
Michael

Christopher Schultz wrote:
> 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

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



-- 

TNG Technology Consulting GmbH, Betastr. 13a, D-85774 Unterföhring
Geschäftsführer: Henrik Klagges, Gerhard Müller, Christoph Stock
Amtsgericht München, HRB 135082



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



Tomcat LoadBalancing

2010-10-13 Thread Deepak Pal

Hello All,

I am new to this mailing list and want to know about Tomcat Load 
Balancing. I have searched a lot but I found only ways to establish a 
Tomcat load balancer by using apache HTTP web server as a front end load 
balancer. but I want a load balancer in which tomcat master handles all 
the requests and balance them on other tomcat instances and receives 
responses from them back.


I will be very appreciable if anyone give me some idea or some document 
about that.


Thanks in advance.

Regards
Deepak

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



RE: Tomcat performance under low load

2010-10-13 Thread Caldarale, Charles R
> From: Vijay Menon [mailto:vijay_me...@hotmail.com] 
> Subject: Tomcat performance under low load

> The other test scenario is where the tomcat instance is kept 
> idle and a single request is sent in every 90 or so seconds.
> In this case, the response takes about 8 seconds out of which
> about 6 seconds cannot be tracked.

What do you measure if you send such requests directly to Tomcat, not via httpd?

 - 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



Tomcat performance under low load

2010-10-13 Thread Vijay Menon

Hi all
Thanks for reading this post. 
We are currently having 2 requirements that are opposites. The first 
requirement is performance under high loads and the other one is equivalent 
performance for 1 request.
Our prod env currently uses Apache with mod_jk and ajp 1.3 to Tomcat 6.0.26 and 
jdk 1.6.0_18 on solaris.
We're scaling to satisfactory loads of 250 concurrent requests serving pages in 
0.5 seconds.
The other test scenario is where the tomcat instance is kept idle and a single 
request is sent in every 90 or so seconds. In this case, the response takes 
about 8 seconds out of which about 6 seconds cannot be tracked.
As the result, what we're finding is that under high loads, it performs well 
but under very low loads, it does not.
This definitely happens in the tomcat layer as we've used the 
FastCommonAccessLogValve logger which gives the time for the request in Tomcat.
The connector properties are protocol="AJP/1.3" maxThreads="150" 
minSpareThreads="25" maxSpareThreads="75" acceptCount="100" 
connectionTimeout="2" disableUploadTimeout="true" 
useBodyEncodingForURI="true".
I was wondering whether anyone would be able to help with this issue.
Thanks in advance
VM

RE: Disable class monitoring for reloading container classes

2010-10-13 Thread Jane Muse
The IBM I uses its own integrated file system (IFS). You can access it
locally with map network drives, but my tests did not involve doing
that.

Jane

-Original Message-
From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] 
Sent: Wednesday, October 13, 2010 3:20 PM
To: Tomcat Users List
Subject: RE: Disable class monitoring for reloading container classes

That was me in another thread.  Here's what I stated:

"It just occurred to me that I don't think anyone's asked if these are
net-mounted file systems.  I've seen this timestamp-shifting before, but
only on net-mounted filesystems.  Usually the source and local systems
are set to different timezones (or DST settings)."

Jeff

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, October 13, 2010 1:21 PM
> To: Tomcat Users List
> Subject: Re: Disable class monitoring for reloading container classes
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Jane,
> 
> On 10/13/2010 1:40 PM, Jane Muse wrote:
> > Thanks for the java program Chris, I ran it on the version of the 
> > O/S where we get the problem and got results that show a last 
> > modified date that differs by one hour when the time changes due to
DST.
> >
> > Current GMT time (no DST): 2010-10-12 22:53:27 GMT  Current local 
> > time (with DST): 2010-10-12 15:53:28 PDT  File 
> > [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar]
> >  last modified timestamp: 1231267693000  the file was last modified 
> > 55656315 seconds ago  last modified as GMT time (no DST): 2009-01-06

> > 18:48:13 GMT  last modified as local time: 2009-01-06 10:48:13 PST
> >
> > Change date to: 03/13/10
> >
> > java com.aldon.lifetime.permissions.test.TimeChange
> '/Aldon/Aldonls/tomcat20/lib/servlet-api.jar'
> > Current GMT time (no DST): 2010-03-13 23:55:24 GMT Current local 
> > time (with DST): 2010-03-13 15:55:24 PST File 
> > [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar]
> > last modified timestamp: 1231271293000 the file was last modified 
> > 37253231 seconds ago last modified as GMT time (no DST): 2009-01-06 
> > 19:48:13 GMT last modified as local time: 2009-01-06 11:48:13 PST
> >
> > IBM has said they'll open a discussion with their development team 
> > and try to get a fix out.
> 
> Someone had a suggestion about the use of NFS. Are you using a remote 
> filesystem that might be mutating the file timestamps?
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAky1+KIACgkQ9CaO5/Lv0PA0aQCffNfPI8JGlH9wrzRbzw9rFg9L
> DCgAnjKwE1Nodu6cj180aKqVfv5pvXBs
> =ki8t
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


__

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



RE: Disable class monitoring for reloading container classes

2010-10-13 Thread Jeffrey Janner
That was me in another thread.  Here's what I stated:

"It just occurred to me that I don't think anyone's asked if these are 
net-mounted file systems.  I've seen this timestamp-shifting before, but only 
on net-mounted filesystems.  Usually the source and local systems are set to 
different timezones (or DST settings)."

Jeff

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, October 13, 2010 1:21 PM
> To: Tomcat Users List
> Subject: Re: Disable class monitoring for reloading container classes
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Jane,
> 
> On 10/13/2010 1:40 PM, Jane Muse wrote:
> > Thanks for the java program Chris, I ran it on the version of the O/S
> > where we get the problem and got results that show a last modified
> > date that differs by one hour when the time changes due to DST.
> >
> > Current GMT time (no DST): 2010-10-12 22:53:27 GMT
> >  Current local time (with DST): 2010-10-12 15:53:28 PDT
> >  File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar]
> >  last modified timestamp: 1231267693000
> >  the file was last modified 55656315 seconds ago
> >  last modified as GMT time (no DST): 2009-01-06 18:48:13 GMT
> >  last modified as local time: 2009-01-06 10:48:13 PST
> >
> > Change date to: 03/13/10
> >
> > java com.aldon.lifetime.permissions.test.TimeChange
> '/Aldon/Aldonls/tomcat20/lib/servlet-api.jar'
> > Current GMT time (no DST): 2010-03-13 23:55:24 GMT
> > Current local time (with DST): 2010-03-13 15:55:24 PST
> > File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar]
> > last modified timestamp: 1231271293000
> > the file was last modified 37253231 seconds ago
> > last modified as GMT time (no DST): 2009-01-06 19:48:13 GMT
> > last modified as local time: 2009-01-06 11:48:13 PST
> >
> > IBM has said they'll open a discussion with their development team
> > and try to get a fix out.
> 
> Someone had a suggestion about the use of NFS. Are you using a remote
> filesystem that might be mutating the file timestamps?
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAky1+KIACgkQ9CaO5/Lv0PA0aQCffNfPI8JGlH9wrzRbzw9rFg9L
> DCgAnjKwE1Nodu6cj180aKqVfv5pvXBs
> =ki8t
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

__

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

2010-10-13 Thread Jeffrey Janner
I just realized that I somehow replied to the wrong thread on this one.
It was meant for Jane Muse's thread.
I'll repost there in case someone missed it.
Sorry to interrupt your thread with irrelevant information/spleculation.
Jeff

> -Original Message-
> From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
> Sent: Tuesday, October 12, 2010 2:23 PM
> To: Tomcat Users List
> Subject: RE: Error 503 ocurring when server under load
> 
> I just occurred to me that I don't think anyone's asked if these are
> net-mounted file systems.  I've seen this timestamp-shifting before,
> but only on net-mounted filesystems.  Usually the source and local
> systems are set to different timezones (or DST settings).
> 
> > -Original Message-
> > From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> > Sent: Tuesday, October 12, 2010 1:47 PM
> > To: Tomcat Users List
> > Subject: Re: Error 503 ocurring when server under load
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Rob,
> >
> > On 10/11/2010 4:40 PM, Rob G wrote:
> > > So if I'm reading your email and the docs correctly. I should just
> > > comment out the cachesize=10 from the workers.properties.
> >
> > I would.
> >
> > > And since for connection_pool_size (that replaced it)  JK  will
> > > discover this number for the Apache web server automatically and
> set
> > > the pool size to this value, I don't need to add anything to the
> > > workers.properties file?
> >
> > I believe that is true.
> >
> > On the other hand, there is another case where you might have
> problems.
> > If you have, say, 512 worker threads in Apache httpd but you only
> have,
> > say, 200 request processor threads configured in Tomcat, then you
> will
> > get mod_jk connection failures on the httpd side.
> >
> > I would recommend that you have enough request processors configured
> in
> > Tomcat to handle the expected load.
> >
> > - -chris
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.4.10 (MingW32)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iEYEARECAAYFAky0rToACgkQ9CaO5/Lv0PCvjACgwttZ9YfINxpWP+DI1+VlKfvI
> > OTAAoK+2RQRibL56GdYWlaWxx6obZVln
> > =hY3s
> > -END PGP SIGNATURE-
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> 
> ___
> ___
> 
> 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.
__

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

2010-10-13 Thread Jane Muse
Chuck,

Thanks for your persistence! I'll try to explain with examples.

We have a directory called COMPANY_NAME/tomcat that is CATALINA_BASE. 
I sent the contents of CATALINA_BASE/conf/context.xml in the email
below.
We have a CATALINA_BASE/WEBAPPS/APP_NAME directory.
We also have a COMPANY_NAME/APP_CONF_DIR that contains a /conf
directory, the APP_NAME.war file, and an APP_NAME.xml file. There is a
context element defined in the COMPANY_NAME/APP_CONF/DIR/app_name.xml
file with reloadable="false". This is the one I was changing. However it
turns out that we used this one as a placeholder in case the one in the
CATALINA_BASE/conf/[enginename]/[hostname]/app_name.xml got deleted.

We also have a context element in a place I hadn't seen before at:
CATALINA_BASE/conf/[enginename]/[hostname]/app_name.xml. This context
element had reloadable="true". I changed it to reloadable="false" and
restarted tomcat. Now the app does not get reloaded! Fixed. Thanks to
all.

Jane

-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 
Sent: Wednesday, October 13, 2010 12:57 PM
To: Tomcat Users List
Subject: RE: Disable class monitoring for reloading container classes

> From: Jane Muse [mailto:jm...@aldon.com]
> Subject: RE: Disable class monitoring for reloading container classes

> Here's my context.xml:
> 
> 

That may not be illegal syntax for XML, but it certainly is confusing.
Better to do this:

  

> We are not defining our webapps context file in META-INF/context.xml.
> It is outside the CATALINA_BASE, in a separate directory that contains

> the War file, the context file and a conf directory for the webapp.

See below for your self-contradictory statement.

> Here's the contents of the .xml file:

Which is located where?

>  Beginning of data**  docBase=">/>webapp>.war"
>  path=""
>  reloadable="false">
> 

That's even more confusing and definitely not valid syntax, as well as
having an illegal path attribute.

> "" is the name of the webapp directory in 
> /webapps/.

So is your webapp in /webapps or not?

 - 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


-
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-13 Thread Caldarale, Charles R
> From: Jane Muse [mailto:jm...@aldon.com] 
> Subject: RE: Disable class monitoring for reloading container classes

> Here's my context.xml:
> 
> 

That may not be illegal syntax for XML, but it certainly is confusing.  Better 
to do this:

  

> We are not defining our webapps context file in META-INF/context.xml.
> It is outside the CATALINA_BASE, in a separate directory that contains
> the War file, the context file and a conf directory for the webapp.

See below for your self-contradictory statement.

> Here's the contents of the .xml file:

Which is located where?

>  Beginning of data**
>   docBase=">/>webapp>.war"
>  path=""
>  reloadable="false">
> 

That's even more confusing and definitely not valid syntax, as well as having 
an illegal path attribute.

> "" is the name of the webapp directory in
> /webapps/.

So is your webapp in /webapps or not?

 - 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-13 Thread Jane Muse
Here's my context.xml:

 Beginning of data**





 


 





 

 


 





 

  

 


_

We are not defining our webapps context file in META-INF/context.xml. It
is outside the CATALINA_BASE, in a separate directory that contains the
War file, the context file and a conf directory for the webapp. Here's
the contents of the .xml file:

 Beginning of data**



_

"" is the name of the webapp directory in
/webapps/.

Jane  
 End of Data  

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jane,

On 10/13/2010 1:51 PM, Jane Muse wrote:
> I found that reloadable="false" does not suppress tomcat from watching

> if files change in WEB-INF/lib, even though the docs say it does:

Please log a bug. Note that bugs logged against old versions of Tomcat
(6.0.18 is over two years old) are often met with "upgrade to latest,
then retest" instructions.

Upgrading would certainly be a good idea in general.

> Can I safely say I've run into both an IBM and a tomcat bug?

I'm not convinced that either are true, honestly. There are plenty of
explanations that do not require either your OS or Tomcat to have a bug.

> I'm on
> tomcat 6.0.18 and I've searched the 6.0.29 change logs, didn't see 
> anything for this issue that's been fixed.

We run in production on 5.5.x and 6.0.x both with default "reloadable"
values (that is, "false") and changes to files in WEB-INF/classes and
WEB-INF/lib do not trigger automatic reloads. My experience leads me to
believe that Tomcat works properly and that your configuration is
somehow broken.

Can you post your TOMCAT_HOME/conf/context.xml file as well as your
webapp's META-INF/context.xml file? Take care to remove sensitive
information, particularly from the latter.

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

iEYEARECAAYFAky1+a8ACgkQ9CaO5/Lv0PAVswCfaSG12tBF+pILKASF6TKMQatf
XvcAoL13iNq5KfXdTljWjAxg6TAl9Hns
=k6mc
-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: Insonsistent output of Java 5 enums

2010-10-13 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Oliver,

On 10/10/2010 5:29 AM, Oliver Siegmar wrote:
> I'm a bit confused about how differed Java 5 enums are handled in JSPs. I 
> have 
> an enum that has an overridden toString() method.
> 
> My JSP looks like this:
> 
> Output per EL: ${myEnumValue} 
> Output per JSTL: 
> 
> The output is:
> 
> Output per EL: VALID
> Output per JSTL: valid result, code 0

What do your taglib declarations look like? I've only used the JSTL a
little bit, and I found that when you have the wrong taglib URL, things
don't work properly.

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

iEYEARECAAYFAky2Br0ACgkQ9CaO5/Lv0PDGywCfYzGC04+VnY4wdP5KvXFqUCIk
2GQAoKwcFGmuul4sXCWjBxtJ+Ig72yyD
=pnsq
-END PGP SIGNATURE-

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



Re: NullPointerException when Tomcat calls org.apache.catalina.connector.Request.parseParameters

2010-10-13 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dave,

Resurrecting this thread from last week.

On 10/7/2010 2:53 PM, laredotornado wrote:
> You are correct.  This stack trace came from a server with 6.0.13 installed. 
> We also observed this in our environment with 6.0.24.

Can you give us the stack trace from 6.0.24?

The line of code for 6.0.13 is this:

2426   if (!getMethod().equalsIgnoreCase("POST"))
2427  return;

The only dereferencing that's going on is against the return from
getMethod, since 'this' can never be null. I don't understand why the
request method would be null.

Can you provide an access log which shows some basic information about
the request (particularly, the HTTP method being used at the time)?

I do know that older versions of Tomcat would allow just any HTTP method
(including nonsense ones like FOOBAR) to be invoked against a JSP. At
some point, it was changed so that a JSP could only respond to (IIRC)
GET and POST. For these old versions, it's possible that a null method
could hit a JSP and trigger this error.

> Right now, it is not
> an option to upgrade.

That's too bad. You should get the latest version (6.0.29) into testing
ASAP: 6.0.13 is over 3 years old and Tomcat has had significant security
improvements since then.

> Is there a work-around?

I would guess that you have a client that is sending a bad HTTP request,
honestly. Is this reproducible? Or are you just seeing errors in your
log files?

> Below is the connector info
> from our server.xml file and the request from the Net panel of Firebug.

The connector configuration shouldn't matter.

> Params:
> next  save
> 
> Response Headers:
> Date  Thu, 07 Oct 2010 18:30:35 GMT
> ServerApache/2.2.4 (Unix) mod_jk/1.2.25
> Location  http://laughlin-qa.criticalmass.com:8100//meetings/rfp/save.jsp
> Vary  User-Agent,Accept-Encoding
> Content-Encoding  gzip
> Keep-Alivetimeout=10
> ConnectionKeep-Alive
> Transfer-Encoding chunked
> Content-Type  text/html;charset=UTF-8
> 
> request headers:
> Request Headersview source
> Host  laughlin-qa.criticalmass.com:8100
> User-AgentMozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;

Hmm... I would expect Firefox to be a decent client :)

I can't tell from this listing: what did the request line look like that
went to the server?

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

iEYEARECAAYFAky2BhwACgkQ9CaO5/Lv0PAF0QCfbg410jchJ1x9iq1P62vbSpvD
pdkAnA85T1th2GHWGEBaD9gXYQryzOp0
=6D5N
-END PGP SIGNATURE-

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



Re: connection pool

2010-10-13 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tomaz,

On 10/11/2010 4:08 AM, TomazM wrote:
> Why if I reload application which use connection pool doesn't release 
> connection's to MySQL DB?
> 
> Only if I restart Tomcat connection's are released, is this a bug.

Yes, it is: https://issues.apache.org/bugzilla/show_bug.cgi?id=22626

Remy has chosen not to fix this. I disagree with his reasons, but he's
the Tomcat dev, not me.

I wrote the ServletContextListener shown below to close-down my JNDI
DataSource when my app is taken out of service. I believe the DataSource
itself still hangs around after the webapp is stopped, but at least the
database connections should be closed.

Feel free to use this code however you want.

Configure it in web.xml like this:


...

  JNDIDataSourceName
  jdbc/myDataSource

...


JNDIDataSourceShutdownListener



Here is the code:

import java.sql.SQLException;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

import javax.sql.DataSource;

import javax.servlet.ServletContext;
import javax.servlet.ServletContextListener;
import javax.servlet.ServletContextEvent;

/**
 * A listener to shut down the JNDI DataSource created by Tomcat
 * (but not automatically cleaned up).
 *
 * @author Chris Schultz
 * @version $Revision: 1.1 $ $Date: 2009-08-06 16:42:32 $
 */
public class JNDIDataSourceShutdownListener
implements ServletContextListener
{
private String _dataSourcePath;

public void contextInitialized(ServletContextEvent e)
{
ServletContext application = e.getServletContext();

_dataSourcePath
= application.getInitParameter("JNDIDataSourceName");

if(!_dataSourcePath.startsWith("java:"))
_dataSourcePath = "java:/comp/env/" + _dataSourcePath;
}

/**
 * Attempts to close the DataSource
 */
public void contextDestroyed(ServletContextEvent e)
{
ServletContext application = e.getServletContext();

try
{
Context ctx = new InitialContext();

DataSource ds = (DataSource)ctx.lookup(_dataSourcePath);

if(null == ds)
{
application.log(getClass().getName()
+ ": No DataSource found at "
+ _dataSourcePath);
}
else
{
application.log(getClass().getName()
+ ": Closing DataSource "
+ _dataSourcePath);

close(ds, application);

application.log(getClass().getName()
+ ": Closed DataSource "
+ _dataSourcePath);
}
}
catch (NamingException ne)
{
application.log(getClass().getName()
+ ": Unable to locate DataSource at "
+ _dataSourcePath, ne);
}
}

private void close(DataSource ds, ServletContext application)
{
try
{
Method closeMethod = ds.getClass().getMethod("close", null);

if(null == closeMethod)
throw new NoSuchMethodException(ds.getClass().getName()
+ ".close()");
closeMethod.invoke(ds, null);
}
catch (Exception e)
{
application.log(getClass().getName()
+ ": Cannot close DataSource", e);
}
}
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky2AMEACgkQ9CaO5/Lv0PBE4ACgwLhTvCee8UAppLiljqlWLvyx
ErYAoLDHyFdoEIsW2riByd7ykuQNQ08R
=ZUk2
-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

2010-10-13 Thread Mark Thomas
On 13/10/2010 19:14, Christopher Schultz wrote:
> Mark,
> 
> On 10/12/2010 5:28 PM, Mark Thomas wrote:
>> On 12/10/2010 19:45, Christopher Schultz wrote:
>>> markt marked this bug as FIXED, but I see no indication of a resolution.
>>> Perhaps that was meant to be WONTFIX?
> 
>> Nope. I meant FIXED. As in "There is now an option you can use to
>> disable this behaviour if you don't like it".
> 
> Gotcha. It wasn't clear from the comment that the fix was somewhat of a
> workaround.
> 
> Any reason those buffers never release their memory?

I believe performance.

> Was the complexity
> of the proposed fix deemed too high for the rare cases where this
> problem occurs (that is, shoddy JSPs)?

I believe so but to be honest I haven't looked at the proposed fix for
quite some time.

> Finally, is this same technique
> used in Tomcat 6.x and is the same workaround available?

6.0.x and 7.0.x. Same workaround.

Mark

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



Re: Starting/Stopping Tomcat from Java program

2010-10-13 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rob,

On 10/11/2010 8:43 AM, Rob Gregory wrote:
> I call the scripts via code to both stop and start Tomcat. There is a
> problem with even calling these scripts via Unix unless you change (cd)
> into the bin directory before running startup.sh as the log paths are
> generated relative to the startup.sh location.

The cwd of the process is irrelevant: the script determines the Tomcat
directory from the location of the script itself.

>   String strCatalinaBin = System.getenv("CATALINA_HOME") +
> "\\bin\\";
>   File objDir = new File(strCatalinaBin);
>   r = Runtime.getRuntime();
>   p = r.exec(new String[] { "cmd.exe", "/C", "start",
> strCatalinaBin + "catalina.bat", "start" }, null, objDir);

Note that you are not invoking catalina.bat directly, but instead
invoking the "start" command to invoke catalina.bat.

>   p.waitFor();
>   p.destroy();

This may stall if the script generates more than a trivial amount of
input. It's always best to drain both the stdout and stderr streams of
any process you launch in order to avoid hangups.

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

iEYEARECAAYFAky1/rQACgkQ9CaO5/Lv0PDFbACgn6vDOcb0IswVezPZ0NwRdIWi
hZEAoJWH8NM9czRxSY49nO7uzPJxTZ0q
=yWZ2
-END PGP SIGNATURE-

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



Re: APR based tomcat native library not found

2010-10-13 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

To whom it may concern,

On 10/12/2010 11:00 AM, efftronics wrote:
> I am running apache tomcat 6.0.18 , java 1.6 on windows xp platform.
> I copied tcnative-1.dll  and openssl.exe(1.1.14 version) in
>  C:\apache-tomcat-6.0.18\bin . But i when i run 
> startup.bat it showing that "APR based tcnative library not found".

It should also dump the value for the system property java.library.path.
What value does it show there?

Note that Tomcat 6.0.18 is over 2 years old. Consider upgrading to the
latest.

> I also tried with 1.1.8,1.1.0,1.1.19,1.1.20 APR libraries but there
> is no use.Plaease help me.Which version i have to use.Please provide
> the link.

http://tomcat.apache.org/tomcat-6.0-doc/apr.html

Note the following, directly from the above link:

"Windows binaries are provided for tcnative-1, which is a statically
compiled .dll which includes OpenSSL and APR."

That means you don't need openssl.exe at all unless you have chosen to
use separate, dynamically linked .dll files. It looks like you're doing
a little of both. If you use separate .dlls, you need: tcnative.dll,
apr.dll, and some kind of openssl library (it's unclear if you need
openssl.exe or something else).

The binaries I find for 1.1.20 say they were built against APR 1.3.9 and
OpenSSL 0.9.8k.

So, it sounds like you need to:

1. Use the OpenSSL version that is expected (0.9.8k instead of whatever
1.1.14 is)

2. Add the APR .dll

3. Double-check your java.library.path and make sure the .dll files are
in there somewhere (or change your java.library.path)

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

iEYEARECAAYFAky1/LQACgkQ9CaO5/Lv0PDOnwCfciNI61IEMvq4g7dzDbt0bYDg
1NkAnj3qT3rTNL/6n8/KTMZI9kmpK72y
=sWhT
-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

2010-10-13 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jane,

On 10/13/2010 1:51 PM, Jane Muse wrote:
> I found that reloadable="false" does not suppress tomcat from watching
> if files change in WEB-INF/lib, even though the docs say it does: 

Please log a bug. Note that bugs logged against old versions of Tomcat
(6.0.18 is over two years old) are often met with "upgrade to latest,
then retest" instructions.

Upgrading would certainly be a good idea in general.

> Can I safely say I've run into both an IBM and a tomcat bug?

I'm not convinced that either are true, honestly. There are plenty of
explanations that do not require either your OS or Tomcat to have a bug.

> I'm on
> tomcat 6.0.18 and I've searched the 6.0.29 change logs, didn't see
> anything for this issue that's been fixed.

We run in production on 5.5.x and 6.0.x both with default "reloadable"
values (that is, "false") and changes to files in WEB-INF/classes and
WEB-INF/lib do not trigger automatic reloads. My experience leads me to
believe that Tomcat works properly and that your configuration is
somehow broken.

Can you post your TOMCAT_HOME/conf/context.xml file as well as your
webapp's META-INF/context.xml file? Take care to remove sensitive
information, particularly from the latter.

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

iEYEARECAAYFAky1+a8ACgkQ9CaO5/Lv0PAVswCfaSG12tBF+pILKASF6TKMQatf
XvcAoL13iNq5KfXdTljWjAxg6TAl9Hns
=k6mc
-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

2010-10-13 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jane,

On 10/13/2010 1:40 PM, Jane Muse wrote:
> Thanks for the java program Chris, I ran it on the version of the O/S
> where we get the problem and got results that show a last modified
> date that differs by one hour when the time changes due to DST.
> 
> Current GMT time (no DST): 2010-10-12 22:53:27 GMT 
>  Current local time (with DST): 2010-10-12 15:53:28 PDT 
>  File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar] 
>  last modified timestamp: 1231267693000 
>  the file was last modified 55656315 seconds ago
>  last modified as GMT time (no DST): 2009-01-06 18:48:13 GMT
>  last modified as local time: 2009-01-06 10:48:13 PST   
> 
> Change date to: 03/13/10
> 
> java com.aldon.lifetime.permissions.test.TimeChange 
> '/Aldon/Aldonls/tomcat20/lib/servlet-api.jar' 
> Current GMT time (no DST): 2010-03-13 23:55:24 GMT
> 
> Current local time (with DST): 2010-03-13 15:55:24 PST
> 
> File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar]
> 
> last modified timestamp: 1231271293000
> 
> the file was last modified 37253231 seconds ago   
> 
> last modified as GMT time (no DST): 2009-01-06 19:48:13 GMT   
> 
> last modified as local time: 2009-01-06 11:48:13 PST 
> 
> IBM has said they'll open a discussion with their development team
> and try to get a fix out.

Someone had a suggestion about the use of NFS. Are you using a remote
filesystem that might be mutating the file timestamps?

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

iEYEARECAAYFAky1+KIACgkQ9CaO5/Lv0PA0aQCffNfPI8JGlH9wrzRbzw9rFg9L
DCgAnjKwE1Nodu6cj180aKqVfv5pvXBs
=ki8t
-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

2010-10-13 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Anurag,

On 10/12/2010 5:47 PM, Anurag Kapur wrote:
> I have probably attached an incomplete snapshot of the memory
> utilization graph.

I'm only looking at what is on your blog. That graph looks good. Perhaps
you could update your blog with a graph that illustrates your conclusion.

> I have done a few tests with the JVM argument suggested in the bug
> report. The initial tests look good.

Good.

> Also, yes, ours being a content management application, we have large
> body tags. We use several tag libraries that come with the CMS
> implementation to fetch content from the CMS.

Usually CMS applications /manage/ content, rather than hard-coding it.
What kind of huge body tags do you have?

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

iEYEARECAAYFAky193MACgkQ9CaO5/Lv0PC8ZwCeOCRg4pGeK7QjTVkeV7tNJUcD
GBgAnRO63f4ed/ZRewJcgLC7FwJwLg20
=ZC7S
-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

2010-10-13 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark,

On 10/12/2010 5:28 PM, Mark Thomas wrote:
> On 12/10/2010 19:45, Christopher Schultz wrote:
>> markt marked this bug as FIXED, but I see no indication of a resolution.
>> Perhaps that was meant to be WONTFIX?
> 
> Nope. I meant FIXED. As in "There is now an option you can use to
> disable this behaviour if you don't like it".

Gotcha. It wasn't clear from the comment that the fix was somewhat of a
workaround.

Any reason those buffers never release their memory? Was the complexity
of the proposed fix deemed too high for the rare cases where this
problem occurs (that is, shoddy JSPs)? Finally, is this same technique
used in Tomcat 6.x and is the same workaround available?

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

iEYEARECAAYFAky19ugACgkQ9CaO5/Lv0PBRFACgistXA3G55lUJ9hE4Yp43Op/9
CJAAn03E1e/3lxhu6sz3d+/Cj1H+hiP0
=3ZzW
-END PGP SIGNATURE-

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



Re: unable to access comm ports on apache tomcat 6.0.18

2010-10-13 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ramkumar,

On 10/12/2010 11:43 PM, ramkumar wrote:
> Thank you for your response. I dont the communication api version  i
> think it is 2.0.

They are on 3.0, now.

http://www.oracle.com/technetwork/java/index-jsp-141752.html

> I searched for latest version but i could not find it for
> windows OS. I get it from some uploader site.

There don't appear to be any implementations for Microsoft Windows.

What "uploader site" did you get it from? I generally don't just
download stuff randomly from unrecognized sites. I guess many Microsoft
Windows users do that.

- From the Java Communication API download page:

"
Sun no longer offer's the Windows platform binaries of javax.comm,
however javax.comm 2.0.3 can be used for the Windows platform, by using
it in conjunction with the Win32 implementation layer provided by the
RxTx project. To use that, download javax.comm for the 'generic'
platform (which provides the front-end javax.comm API only, without
platform specific back-end implementations bundled). Then acquire the
Windows binary implementation rxtx-2.0.7pre1 from http://www.rxtx.org.
"

Sounds relatively straightforward to me.

Boy, Sun/Oracle's website is impossible to navigate. Trying to find that
download page basically required Google. :(

> My WEB-INF\LIB has following jar files

Your project's lib directory is a complete mess.

As Pid points out, you have a lot of libraries in there that aren't
appropriate: remove all the Tomcat-related stuff and maybe put the
java-comm.jar or whatever it's called in there.

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

iEYEARECAAYFAky19mcACgkQ9CaO5/Lv0PC++ACfahxbaFo3UL1FwnMkIJmJp+mr
PUMAoJprTKTCTm9EP1aECFiOvIuqJYUI
=abKJ
-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

2010-10-13 Thread Jane Muse
Chris,

I found that reloadable="false" does not suppress tomcat from watching
if files change in WEB-INF/lib, even though the docs say it does: 

"Set to true if you want Catalina to monitor classes in
/WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically reload
the web application if a change is detected. " 

True, there is a bug in the IBM O/S where when DST hits, last modified
date for a file gets interpreted as one hour difference. But if
reloadable="false" was working as it says it should, that would be a way
to get around this bug.

Can I safely say I've run into both an IBM and a tomcat bug? I'm on
tomcat 6.0.18 and I've searched the 6.0.29 change logs, didn't see
anything for this issue that's been fixed.

Thanks,
Jane 

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jane,

On 10/9/2010 11:09 AM, Jane Muse wrote:
> My understanding from the docs is that reloading="false" means you 
> can't drop in a war file while tomcat is running and expect it to 
> deploy.

No,  ("reloading" is meaningless) means that
Tomcat will ignore any files within a webapp that have been updated.
 means that Tomcat will not look for .war files
and automatically deploy them.

> reloading="false" means tomcat is not listening / watching if 
> something changes in WEB-INF/classes or WEB-INF/web.xml, and reload if

> there's a change.

Correct, if s/reloading/reloadable/.

> If that's what these mean, then we don't need them.

Generally speaking, it's best to set both of these to "false" in
production because you don't want anything to happen automatically.

> We don't have "WatchedResource" set anywhere either. If anyone knows 
> of a way to suppress tomcat from watching if something in WEB-INF/lib 
> has changed, I think that might work here.

 ought to do the trick.

> But apparently tomcat is hard wired to reload if it thinks there's a 
> change in that directory.

Only if reloadable="true", which is NOT the default.

> I'm not sure if that would be considered a bug in the O/S, or the JVM,

> or if tomcat can be made to suppress watching this, similar to what 
> the autoDeploy and reloading settings provide. Let's put it this way, 
> it would be a lot easier to get a change made to tomcat than to IBM's 
> O/S, or Oracle's JVM 8-)

Agreed, but it's hard to imagine how this situation would be detectable.

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

iEYEARECAAYFAky0pcQACgkQ9CaO5/Lv0PAmfwCfRHBsjuVKjBB6mGswfiZ4jHMk
TvIAoL/EYf/iIcSsdM0u6eVYs4AwOLfI
=mcCD
-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

2010-10-13 Thread Jane Muse
Thanks for the java program Chris, I ran it on the version of the O/S where we 
get the problem and got results that show a last modified date that differs by 
one hour when the time changes due to DST.

Current GMT time (no DST): 2010-10-12 22:53:27 GMT 
 Current local time (with DST): 2010-10-12 15:53:28 PDT 
 File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar] 
 last modified timestamp: 1231267693000 
 the file was last modified 55656315 seconds ago
 last modified as GMT time (no DST): 2009-01-06 18:48:13 GMT
 last modified as local time: 2009-01-06 10:48:13 PST   

Change date to: 03/13/10

java com.aldon.lifetime.permissions.test.TimeChange 
'/Aldon/Aldonls/tomcat20/lib/servlet-api.jar' 
Current GMT time (no DST): 2010-03-13 23:55:24 GMT  
  
Current local time (with DST): 2010-03-13 15:55:24 PST  
  
File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar]  
  
last modified timestamp: 1231271293000  
  
the file was last modified 37253231 seconds ago 
  
last modified as GMT time (no DST): 2009-01-06 19:48:13 GMT 
  
last modified as local time: 2009-01-06 11:48:13 PST 

IBM has said they'll open a discussion with their development team and try to 
get a fix out. 

Thanks to everyone for all the help.

Jane  

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 10/10/2010 9:09 AM, André Warnier wrote:
> What would be really nice, is if someone wrote a quick Java equivalent 
> to the perl script I submitted.

See below. There's actually more code than absolutely necessary, but it's more 
straightforward this way.

> Now if you *really* insist, the modified version of the perl program, 
> below, will explicitly use a couple of C functions, themselves using 
> the builtin C structures to get the file's "last modified" time.
> 
> Running C in perl, scary stuff..

Are you submitting an application for an obfuscated C program, here?
Sheesh. What's wrong with a little C code?

Amazing: the C code is shorter than the Java code. *shrug*

Time.java (apologies for any re-formatting done by my emailer)
- -

import java.io.File;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.TimeZone;

public class Time
{
public static void main(String[] args)
throws Exception
{
if(args.length < 1)
{
System.out.println("Usage: java Time ");
System.exit(1);
}

// GMT current time
Calendar now = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
System.out.println("Current GMT time (no DST): "
   + format(now));

// local current time
now = Calendar.getInstance(); // default = local
System.out.println("Current local time (with DST): "
   + format(now));

// File timestamp
System.out.println("File [" + args[0] + "]");
File file = new File(args[0]);

long timestamp = file.lastModified();

System.out.println("last modified timestamp: " + timestamp);
System.out.println("the file was last modified "
   + ((System.currentTimeMillis() - timestamp) /
1000)
   + " seconds ago");
Calendar tstamp = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
tstamp.setTimeInMillis(file.lastModified());

System.out.println("last modified as GMT time (no DST): "
   + format(tstamp));

tstamp = Calendar.getInstance(); // default=local
tstamp.setTimeInMillis(file.lastModified());

System.out.println("last modified as local time: "
   + format(tstamp));
}

public static String format(Calendar c)
{
SimpleDateFormat format = new SimpleDateFormat("-MM-dd HH:mm:ss z");
//format.setTimeZone(tz);
format.setTimeZone(c.getTimeZone());

return format.format(c.getTime());
}
}

time.c
- --
#include 
#include 
#include 
#include 

int main(int argc, char *argv[]) {
  time_t now;
  struct tm *gmt;
  struct tm *local;
  struct stat *fileinfo;
  int retval;
  char *filename;

  if(argc < 2) {
printf("missing filename\n");
return 1;
  }
  filename = argv[1];

  gmt   = (struct tm*)malloc(sizeof(struct tm));
  local = (struct tm*)malloc(sizeof(struct tm));

  time(&now);

  gmtime_r(&now, gmt);
  localtime_r(&now, local);

  /* note: as

Re: Is there a Bug with JConsole for monitering TOMCAT 6.0.29 Running on Linux

2010-10-13 Thread Pid
On 13/10/2010 14:35, Karthik Nanjangude wrote:
> Hi
> 
>>> through a firewall
> 
> As I have already told u in the last mail
> 
> 1) We do not have a Firewall

You said you did.

> 2) All our servers are available locally

I didn't understand that, apologies.

> 3) We have several UNIX /LINUX servers
> 
> 4) From WIN 2000 server JKD6/jconsole I am able to connect to UNIX server
>for Monitoring  TOMCAT 6.0.14
>
> 5) From WIN 2000 server JKD6/jconsole I am NOT able to connect to Linux
>server for Monitoring  TOMCAT 6.0.29

What is the output from:

 netstat -tln

on both machines?


> Any more ideas would really help me  . :(?

I would still employ the listener below to ensure the port numbers are
predictable.


p

> Try enabling the "JMX Remote Lifecycle Listener".
> 
>  http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html



0x62590808.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature


RE: Is there a Bug with JConsole for monitering TOMCAT 6.0.29 Running on Linux

2010-10-13 Thread Karthik Nanjangude
Hi

>> through a firewall

As I have already told u in the last mail

1) We do not have a Firewall

2) All our servers are available locally

3) We have several UNIX /LINUX servers

4) From WIN 2000 server JKD6/jconsole I am able to connect to UNIX server
   for Monitoring  TOMCAT 6.0.14

5) From WIN 2000 server JKD6/jconsole I am NOT able to connect to Linux
   server for Monitoring  TOMCAT 6.0.29



Any more ideas would really help me  . :(?


With regards
karthik





-Original Message-
From: Pid [mailto:p...@pidster.com]
Sent: Wednesday, October 13, 2010 5:35 PM
To: Tomcat Users List
Subject: Re: Is there a Bug with JConsole for monitering TOMCAT 6.0.29 Running 
on Linux

On 13/10/2010 12:12, Karthik Nanjangude wrote:
>>> export JAVA_HOME=/opt/java6
>>> echo JAVA_HOME = $JAVA_HOME
>>> export CATALINA_OPTS='-Dcom.sun.management.jmxremote.port=8999
>>> -Dcom.sun.management.jmxremote.ssl=false
>>> -Dcom.sun.management.jmxremote.authenticate=false'
>
> Jconsole of JDK6  = :

If you're connecting through a firewall, you may run into an issue
whereby the second JMX port (the registry port) isn't accessible,
because it's assigned to a random port.

Try enabling the "JMX Remote Lifecycle Listener".

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



p

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



Re: Is there a Bug with JConsole for monitering TOMCAT 6.0.29 Running on Linux

2010-10-13 Thread Pid
On 13/10/2010 12:12, Karthik Nanjangude wrote:
>>> export JAVA_HOME=/opt/java6
>>> echo JAVA_HOME = $JAVA_HOME
>>> export CATALINA_OPTS='-Dcom.sun.management.jmxremote.port=8999
>>> -Dcom.sun.management.jmxremote.ssl=false
>>> -Dcom.sun.management.jmxremote.authenticate=false'
> 
> Jconsole of JDK6  = :

If you're connecting through a firewall, you may run into an issue
whereby the second JMX port (the registry port) isn't accessible,
because it's assigned to a random port.

Try enabling the "JMX Remote Lifecycle Listener".

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



p


0x62590808.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature


RE: Is there a Bug with JConsole for monitering TOMCAT 6.0.29 Running on Linux

2010-10-13 Thread Karthik Nanjangude
Hi

>> I'm not playing chase-the-answer with you

Nither am I , Replying as per u'r mail


>> what details are you putting into the JConsole client instance?

>> export JAVA_HOME=/opt/java6
>> echo JAVA_HOME = $JAVA_HOME
>> export CATALINA_OPTS='-Dcom.sun.management.jmxremote.port=8999
>> -Dcom.sun.management.jmxremote.ssl=false
>> -Dcom.sun.management.jmxremote.authenticate=false'

Jconsole of JDK6  = :




With regards
karthik



-Original Message-
From: Pid [mailto:p...@pidster.com]
Sent: Tuesday, October 12, 2010 1:43 PM
To: Tomcat Users List
Subject: Re: Is there a Bug with JConsole for monitering TOMCAT 6.0.29 Running 
on Linux

On 12/10/2010 06:53, Karthik Nanjangude wrote:
> Hi
>
>>> Are you connecting through a firewall?
>
> No Firewall ( ALL of these server's are behind the Firewall and the servers 
> are available thru a local hub )
>
> I am able to use Putty (SSH Port 22) to connect to that server for other
> Activities as Start /Srop of TOMCAT 6.0.29 .

There was more than one question in my email.  I'm not playing
chase-the-answer with you, please answer all questions in future.

> How have you set the JMX this time, as below?

Are you connecting through a firewall?

>> Note :
>> Earlier I had configured the same for UNIX / Windows for JConsole  to Tomcat 
>> 6.0.14
>> URL :  http://old.nabble.com/JMX---jconsole-for-TOMCAT6.0.14-td17778173.html

Also: what details are you putting into the JConsole client instance?
Are you specifying a host and a port, or are you specifying a full
'service' URI?

E.g.
service:jmx:rmi://www.hostname.com:port1/jndi/rmi://www.hostname.com:port2/jmxrmi



p




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



Re: unable to access comm ports on apache tomcat 6.0.18

2010-10-13 Thread Pid *
On 13 Oct 2010, at 04:44, ramkumar  wrote:

> Hi,
>Thank you for your response. I dont the communication api version  i
> think it is 2.0. I searched for latest version but i could not find it for
> windows OS. I get it from some uploader site. My WEB-INF\LIB has following
> jar files

Also, which one of these has the Javax.comm api?


p


>(1)commons-logging-1.1.1.jar
>(2)el-api
>(3)jakarta-oro-2.0.8
>(4)jasper
>(5)jasper-el
>(6)jasper-jdt
>(7)jigadmin
>(8)jigedit
>(9)jigsaw
>(10)jmimemagic-0.1.0
>(11)jsp-api log4j-1.2.16
>(12)log4j-over-slf4j-1.6.1
>(13)sax
>(14)slf4j-api-1.6.1
>(15)slf4j-jcl-1.6.1
>(16)smsj-20051126
>(17)Tidy tomcat-coyote
>(18)tomcat-dbcp
>(19)tomcat-i18n-es
>(20)tomcat-i18n-fr
>(21)tomcat-i18n-ja
>(22)xerces xmlsec-1.3.0 xp
>
> -
> 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: unable to access comm ports on apache tomcat 6.0.18

2010-10-13 Thread Pid *
On 13 Oct 2010, at 04:44, ramkumar  wrote:

> Hi,
>Thank you for your response. I dont the communication api version  i
> think it is 2.0. I searched for latest version but i could not find it for
> windows OS. I get it from some uploader site. My WEB-INF\LIB has following
> jar files

Okay... It shouldn't have some of those.

>(1)commons-logging-1.1.1.jar

Remove EL:
>(2)el-api
>(3)jakarta-oro-2.0.8

Remove Jasper:
>(4)jasper
>(5)jasper-el
>(6)jasper-jdt

>(7)jigadmin
>(8)jigedit
>(9)jigsaw
>(10)jmimemagic-0.1.0

Remove JSP
>(11)jsp-api

> log4j-1.2.16
>(12)log4j-over-slf4j-1.6.1
>(13)sax
>(14)slf4j-api-1.6.1
>(15)slf4j-jcl-1.6.1
>(16)smsj-20051126
>(17)Tidy

Remove tomcat:
> tomcat-coyote
>(18)tomcat-dbcp
>(19)tomcat-i18n-es
>(20)tomcat-i18n-fr
>(21)tomcat-i18n-ja


p

>(22)xerces
> -1.3.0 xp
>
> -
> 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: Error 503 ocurring when server under load

2010-10-13 Thread Rob G
On 12 October 2010 19:47, Christopher Schultz
 wrote:
> I would.
>
> I believe that is true.
>
> On the other hand, there is another case where you might have problems.
> If you have, say, 512 worker threads in Apache httpd but you only have,
> say, 200 request processor threads configured in Tomcat, then you will
> get mod_jk connection failures on the httpd side.
>
> I would recommend that you have enough request processors configured in
> Tomcat to handle the expected load.
>
> - -chris
Thanks Chris (and everyone else for their comments).

As an update: I updated Tomcat from 6.0.24 to 6.0.29 and commented out
the cachesize directive from workers.properties. The server ran for a
full day yesterday and not a single 503 error. :) So with a bit of
luck it will continue to work as expected. Of course I'll monitor for
any other issues for the next few days.

Rob

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