date:20090518

means your session to TC is still live
suggest attenuate connectionTimeout in connector config in server.xml

in code you can always session.invalidate()
http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html#invalidate()

Martin Gainty
I have not failed. I've just found 10,000 ways that won't work - edison
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.

From: arvindw...@gmail.com
Date: Mon, 18 May 2009 16:55:30 +0530
Subject: maxwait in dbconnetion is not workiing for first time.
To: users@tomcat.apache.org

This time i have problem in maxwait. To test the maxwait i tried to
establish the connection and close.
My dbserver is located outside my system, so for dbconnection network is
required as per our Production server model.

So first i established the connection first from the jsp page, it gets done.
After that i plugged-out my network cable and tried to make connection by
that same jsp file, but i didnt get exception , it keep on running. but if i
refreshed the page again after few mins the exception is coming. but why not
in first request itself. I need it in first request itself for my failover
model. my maxwait is 1000ms

Resource auth=Container description=Database DSN name=jdbc/dbname
scope=Shareable type=javax.sql.DataSource url=jdbc:postgresql://
1.1.1.180/dbname driverClassName=org.postgresql.Driver username=
password=y maxActive=10 maxIdle=1 minIdle=0
removeAbandoned=true removeAbandonedTimeout=60 logAbandoned=true
maxWait=1000 /

Is it bug or my mistake ?

-Arvind S

*
Many of lifes failure are people who did not realize how close they were to
success when they gave up.
-Thomas Edison*

_
Hotmail® goes with you.
http://windowslive.com/Tutorial/Hotmail/Mobile?ocid=TXT_TAGLM_WL_HM_Tutorial_Mobile1_052009

Apache httpd vs Tomcat static content performance

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

Last week, I decided to actually run my own performance measurements.
Before I waste a lot of time benchmarking, I wanted to vet my
methodology so I get all the data worth taking.

I'm using ApacheBench 2.3 (ships with httpd 2.2.10) as my benchmarking
tool, all running on localhost to avoid anything on my local network
interfering with the tests. I've also blocked all incoming traffic to
the web server using iptables. This machine provides no other services
(except ssh) and is only used by me, so that should be sufficient.

I have 15 static files of sizes 4, 8, 16, 32, 64, 128, and 512
kilobytes, 1, 2, 4, 8, 16, and 32 megabytes. I'm requesting each of them
100,000 times with a concurrency of 1 (single thread makes 100,000
requests). I'm using the Transfer rate (in KiB/sec) as the sample for
each. I have not enabled keepalives, but may for a second set of data.

I will be comparing an out-of-the-box prefork MPM httpd 2.2.10
configuration against an out-of-the-box Tomcat 5.5.26 Coyote, APR, and
APR without sendfile configurations (I didn't realize until after I
started my Coyote tests that NIO is only available in TC6.0, so I'll be
doing my NIO tests on 6.0).

I have a set of numbers for httpd and Coyote already (see below).

I have a few questions for those who wish to comment:

1. Is the number of requests (100, sufficient? It seems to take
   forever on this machine... my Coyote tests took longer than
   overnight.

2. Is a concurrency of 1 okay? I thought about it and testing the
   ability of the OS to schedule processes and threads doesn't seem
   like it adds anything to the data.

3. Is it worth testing without sendfile enabled on those connectors
   that support it? I can reduce the time to generate all the data by
   skipping 3 of the tests.

4. Is transfer rate the best data to use? I suppose that depends on
   what I want to demonstrate. Since we get questions on this list like
   which is faster for static content? I figured that one of two
   things would be appropriate: the transfer rate or the number of
   requests per second. These numbers are directly related, and it's
   easier to graph numbers that are in the same range (you can serve
   a 4KiB file much faster than a 32MiB file), so I chose the former.

Below is the data I've collected so far. I'll publish everything on my
blog, including graphs, etc. once it's finished. (Strange that httpd
dramatically increased its transfer rate when requesting the 16MiB file!)

- -chris

10 Requests localhost   keepalive=off
Concurrency=1   
Transfer Rate (KiB/sec) 
File Size   Apache httpdTC5.5 Coyote
4kiB6215.20 5467.43
8kiB11630.179732.60
16kiB   21271.9216266.66
32kiB   38257.7727530.75
64kiB   63729.1241946.45
128kiB  91768.2356000.19
256kiB  126919.12   72062.84
512kiB  160506.81   66654.86
1MiB180850.63   72533.92
2MiB185157.29   75957.71
4MiB185262.91   77969.20
8MiB185152.66   79075.54
16MiB   256399.66   80364.26
32MiB   189933.50   80243.41
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkoRbeIACgkQ9CaO5/Lv0PAewQCbB7L0jaCWSD6EAcECKIRW/Uy2
AAUAoKpR/2MweDPcnmv3+a+EQd6n55+i
=Jd6Q
-END PGP SIGNATURE-

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

RE: Apache httpd vs Tomcat static content performance

 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Subject: Apache httpd vs Tomcat static content performance

 I will be comparing an out-of-the-box prefork MPM httpd 2.2.10
 configuration against an out-of-the-box Tomcat 5.5.26 Coyote, APR, and
 APR without sendfile configurations (I didn't realize until after I
 started my Coyote tests that NIO is only available in TC6.0, so I'll be
 doing my NIO tests on 6.0).

Better to do it all with Tomcat 6.0; no point in benchmarking levels that are 
under limited development.

What JVM are you using?  I'd recommend a 1.6, preferably in server mode.  
What's the heap size?  Any evidence of GC going on?

What hardware do you have?  I saw no mention of CPU type or RAM or disk.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

RE: Apache httpd vs Tomcat static content performance

2009-05-18 Thread Peter Crowther

 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 1. Is the number of requests (100, sufficient? It seems to take
forever on this machine... my Coyote tests took longer than
overnight.

You want enough tests that they're sensitive to statistically significant 
differences that you're interested in finding.  The tests shouldn't be 
dominated by end effects - startup and shutdown.  I'd be more inclined to run 
*multiple* tests - 3 is about the minimum - to make sure that your single test 
hasn't been messed up by something unexpected.  I'd expect a few minutes per 
test to be enough to ignore end effects; I'd be far more inclined to run 10 
2-minute tests than 1 20-minute test, for example.

 2. Is a concurrency of 1 okay? I thought about it and testing the
ability of the OS to schedule processes and threads doesn't seem
like it adds anything to the data.

Depends.  *Exactly* what are you testing?  If it's who can serve the most 
bytes per second / requests per second, a concurrency of 1 isn't appropriate - 
you want to see what happens as you approach saturation, which is unlikely to 
happen with a single thread.  If it's who can serve load without horrible lock 
contention in the system, same answer.

 Below is the data I've collected so far. I'll publish everything on my
 blog, including graphs, etc. once it's finished. (Strange that httpd
 dramatically increased its transfer rate when requesting the
 16MiB file!)

Looks interesting.  Is there any way of finding out what the rate-limiting 
factor is in each case - CPU, memory bandwidth, memory capacity, disk bandwidth?

- Peter

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

Trouble building tcnative

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

I've never built tcnative before, but I'm no stranger to the standard
UNIX source package build process. I'm having a bit of difficulty
building this.

I'm starting with the bin/tomcat-native.tar.gz that comes with Tomcat
5.5.26 which ends up being tcnative 1.1.12. The README file in that
package says to see native/BUILDING about building the native part of
the package. The path is actually jni/native/BUILDING. Just thought I'd
point that out.

A ./configure with no arguments can't find apr, so I had to tell it
where to find it (I'm using Gentoo Linux which has its own idea about
things, so I'm happy to track these things down). Next, I run:

./configure --with-apr=/usr/bin/apr-1-config

...and this is where things fall apart for me. Here's the output of
configure (apologies for any bad line wrapping):

$ ./configure --with-apr=/usr/bin/apr-1-config
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking for working mkdir -p... yes
Tomcat Native Version: 1.1.12
checking for chosen layout... tcnative
checking for APR... yes
  setting CC to i686-pc-linux-gnu-gcc
  setting CPP to i686-pc-linux-gnu-gcc -E
checking for a BSD-compatible install... /usr/bin/install -c
checking for JDK location (please wait)...
/home/chris/.gentoo/java-config-2/current-user-vm from environment
checking Java platform... checking Java platform...
checking for sablevm... NONE
  adding -I/home/chris/.gentoo/java-config-2/current-user-vm/include
to TCNATIVE_PRIV_INCLUDES
checking os_type directory...  linux
  adding
-I/home/chris/.gentoo/java-config-2/current-user-vm/include/linux to
TCNATIVE_PRIV_INCLUDES
checking for gcc... i686-pc-linux-gnu-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether i686-pc-linux-gnu-gcc accepts -g... yes
checking for i686-pc-linux-gnu-gcc option to accept ISO C89... none needed
checking for OpenSSL library... using openssl from /usr/lib and /usr/include
checking OpenSSL library version... ok
checking for OpenSSL DSA support... yes
  setting TCNATIVE_LDFLAGS to -lssl -lcrypto
  adding -DHAVE_OPENSSL to CFLAGS
  setting TCNATIVE_LIBS to 
  setting TCNATIVE_LIBS to  /usr/lib/libapr-1.la -luuid -lrt -lcrypt
- -lpthread -ldl
./configure: line 4315: APR_BUILD_DIR: command not found
./configure: line 4316: APR_INCLUDES: command not found
./configure: line 4317: APR_LIBS: command not found
./configure: line 4318: APR_LIB_TARGET: command not found
./configure: line 4319: APR_SO_EXT: command not found
./configure: line 4320: BASH: command not found
./configure: line 4321: BASH_ARGC: command not found
./configure: line 4322: BASH_ARGV: command not found
./configure: line 4323: BASH_LINENO: command not found
./configure: line 4324: BASH_SOURCE: command not found
./configure: line 4325: BASH_VERSINFO: command not found
./configure: line 4326: BASH_VERSION: command not found
...

This is followed by hundreds of lines of line xyz: [whatever]: command
not found. Not everything looks like an environment variable or make
variable:

...
./configure: line 4445: _: command not found
./configure: line 4446: abs_builddir: command not found
./configure: line 4447: abs_srcdir: command not found
./configure: line 4448: ac_abs_confdir: command not found
./configure: line 4449: ac_arg: command not found
./configure: line 4450: ac_aux_dir: command not found
./configure: line 4451: ac_build_alias: command not found
./configure: line 4452: ac_c_werror_flag: command not found
...

Then, in the middle of the complaints about unrecognized commands, I see:
...
./configure: line 4611: get_version: command not found
Usage: host [-aCdlriTwv] [-c class] [-N ndots] [-t type] [-W time]
[-R number] [-m flag] hostname [server]
   -a is equivalent to -v -t ANY
   -c specifies query class for non-IN data
   -C compares SOA records on authoritative nameservers
   -d is equivalent to -v
   -l lists all hosts in a domain, using AXFR
   -i IP6.INT reverse lookups
   -N changes the number of dots allowed before root lookup is done
   -r disables recursive processing
   -R specifies number of retries for UDP packets
   -s a SERVFAIL response should stop query
   -t specifies the query type
   -T enables TCP/IP mode
   -v enables verbose output
   -w specifies to wait forever for a reply
   -W specifies how long to wait for a reply
   -4 use IPv4 query transport only
   -6 use IPv6 query transport only
   -m set memory debugging flag (trace|record|usage)
./configure: line 4613: host_alias: command not found
...

Then I

RE: Apache httpd vs Tomcat static content performance

the apache httpd may cry foul because you are testing with a prefork config
instead of worker
assuming you can scare up another processor
is there a way to run the same httpd test suite with apache worker?

assuming the definition data_transfer_rate is accurate
http://en.wikipedia.org/wiki/Transfer_rate#Network_throughput_.28data_transfer_rate.29_and_goodput
data transfer rate refers to the achieved average net bit rate that is
delivered to the application layer, exclusive of all protocol overhead, data
packets retransmissions, etc.
i would be interested to know how you detect protocol overhead and packet
retransmits (to exclude for your data_transfer_rate calculations)

this is good information
Martin
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Date: Mon, 18 May 2009 10:17:06 -0400
From: ch...@christopherschultz.net
To: users@tomcat.apache.org
Subject: Apache httpd vs Tomcat static content performance

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

Last week, I decided to actually run my own performance measurements.
Before I waste a lot of time benchmarking, I wanted to vet my
methodology so I get all the data worth taking.

I'm using ApacheBench 2.3 (ships with httpd 2.2.10) as my benchmarking
tool, all running on localhost to avoid anything on my local network
interfering with the tests. I've also blocked all incoming traffic to
the web server using iptables. This machine provides no other services
(except ssh) and is only used by me, so that should be sufficient.

I have 15 static files of sizes 4, 8, 16, 32, 64, 128, and 512
kilobytes, 1, 2, 4, 8, 16, and 32 megabytes. I'm requesting each of them
100,000 times with a concurrency of 1 (single thread makes 100,000
requests). I'm using the Transfer rate (in KiB/sec) as the sample for
each. I have not enabled keepalives, but may for a second set of data.

I will be comparing an out-of-the-box prefork MPM httpd 2.2.10
configuration against an out-of-the-box Tomcat 5.5.26 Coyote, APR, and
APR without sendfile configurations (I didn't realize until after I
started my Coyote tests that NIO is only available in TC6.0, so I'll be
doing my NIO tests on 6.0).

I have a set of numbers for httpd and Coyote already (see below).

I have a few questions for those who wish to comment:

1. Is the number of requests (100, sufficient? It seems to take
forever on this machine... my Coyote tests took longer than
overnight.

2. Is a concurrency of 1 okay? I thought about it and testing the
ability of the OS to schedule processes and threads doesn't seem
like it adds anything to the data.

3. Is it worth testing without sendfile enabled on those connectors
that support it? I can reduce the time to generate all the data by
skipping 3 of the tests.

4. Is transfer rate the best data to use? I suppose that depends on
what I want to demonstrate. Since we get questions on this list like
which is faster for static content? I figured that one of two
things would be appropriate: the transfer rate or the number of
requests per second. These numbers are directly related, and it's
easier to graph numbers that are in the same range (you can serve
a 4KiB file much faster than a 32MiB file), so I chose the former.

Below is the data I've collected so far. I'll publish everything on my
blog, including graphs, etc. once it's finished. (Strange that httpd
dramatically increased its transfer rate when requesting the 16MiB file!)

- -chris

10 Requests localhost keepalive=off
Concurrency=1
Transfer Rate (KiB/sec)
File Size Apache httpdTC5.5 Coyote
4kiB 6215.20 5467.43
8kiB 11630.179732.60
16kiB 21271.9216266.66
32kiB 38257.7727530.75
64kiB 63729.1241946.45
128kiB91768.2356000.19
256kiB126919.12 72062.84
512kiB160506.81 66654.86
1MiB 180850.63 72533.92

Re: Apache httpd vs Tomcat static content performance

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

On 5/18/2009 10:33 AM, Peter Crowther wrote:
 From: Christopher Schultz [mailto:ch...@christopherschultz.net] 1.
 Is the number of requests (100, sufficient? It seems to take 
 forever on this machine... my Coyote tests took longer than 
 overnight.
 
 You want enough tests that they're sensitive to statistically 
 significant differences that you're interested in finding. The tests 
 shouldn't be dominated by end effects - startup and shutdown. I'd be 
 more inclined to run *multiple* tests - 3 is about the minimum - to
 make sure that your single test hasn't been messed up by something 
 unexpected. I'd expect a few minutes per test to be enough to ignore
 end effects; I'd be far more inclined to run 10 2-minute tests than
 1 20-minute test, for example.

Well, these tests are taking a long time. The size of each file
obviously has an effect on the time it takes to serve 100,000 requests.
I'm running my Coyote/APR tests, now (which I'll throw out, because its
an old version of tcnative AND my site is actively being used right now)
and the 4KiB tests took 54.987 seconds while the 512KiB tests took
344.414 seconds. (I'm happy to say that Coyote/APR is performing on par
with httpd which seems pretty obvious since they should be running
roughly the same code).

I suppose I could gauge each test so it would take (roughly) a certain
amount of time (say, 10 minutes). At least then I'd know how long the
entire battery would take :)

 2. Is a concurrency of 1 okay? I thought about it and testing the 
 ability of the OS to schedule processes and threads doesn't seem 
 like it adds anything to the data.
 
 Depends. *Exactly* what are you testing? If it's who can serve the 
 most bytes per second / requests per second, a concurrency of 1
 isn't appropriate - you want to see what happens as you approach
 saturation, which is unlikely to happen with a single thread. If it's
 who can serve load without horrible lock contention in the system,
 same answer.

Okay. My original test plan included concurrencies of 1, 2, 4, 8, and
16. I think I'll just do 1 and 16 and maybe another one if I get the
time. Maybe I should just get a faster server :)

 Below is the data I've collected so far. I'll publish everything on
 my blog, including graphs, etc. once it's finished. (Strange that
 httpd dramatically increased its transfer rate when requesting the 
 16MiB file!)
 
 Looks interesting.  Is there any way of finding out what the
 rate-limiting factor is in each case - CPU, memory bandwidth, memory
 capacity, disk bandwidth?

That's a good question... if the disk can't read the data any faster,
than the server can't serve the bytes any faster (unless caching is
being used, I suppose, but this is supposed to be out-of-the-box config).

Since this is a relatively old server (1500MHz 32-bit AMD Athlon), I'm
surely being limited by just about everything except memory capacity (it
doesn't take much memory to serve static content). I can easily get
memory timing information, and I suspect my memory timing will
significantly beat the throughput of the TCP stack (shared memory be
damned). I can also benchmark my disk I suppose. Since I already have
the transfer rates for the HTTP responses, I can simply see if the
hardware is significantly faster than the server so rule-out any real
hardware difficulties.

On the other hand, since both servers are running on the same hardware,
the playing-field is at least level: they are already performing
differently from each other, so I think I have a decent basis for
comparison even without doing a detailed hardware analysis.

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

iEYEARECAAYFAkoRfXwACgkQ9CaO5/Lv0PDGbACggVAreYAtvGoEQ6kqT9dhjgCB
kEsAoIij+Lu5Z/y1MAMibpPsg0pF0JGp
=BQWO
-END PGP SIGNATURE-

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

RE: Tomcat not closing threads


some documentation:

http://httpd.apache.org/docs/2.0/mod/mpm_common.html
MaxClients:
The MaxClients directive sets the limit on the number of simultaneous requests 
that will be served. 
Any connection attempts over the MaxClients limit will normally be queued, up 
to a number based on the ListenBacklog directive. 
Once a child process is freed at the end of a different request, the connection 
will then be serviced.
For non-threaded servers (i.e., prefork), MaxClients translates into the 
maximum number of child processes that will be launched to serve requests. The 
default value is 256; to increase it, you must also raise ServerLimit.
For threaded and hybrid servers (e.g. beos or worker) MaxClients restricts the 
total number of threads that will be available to serve clients. 
The default value for beos is 50. 
For hybrid MPMs (your situation) the default value is 16 (ServerLimit) 
multiplied by the value of ThreadsPerChild. 
Therefore, to increase MaxClients to a value that requires more than 16 
processes, you must also raise ServerLimit.

ThreadsPerChild
This directive sets the number of threads created by each child process.
The child creates these threads at startup and never creates more. 
If using an MPM like mpm_winnt, where there is only one child process, this 
number should be high enough to handle the entire load of the server. 
If using an MPM like worker, where there are multiple child processes, the 
total number of threads should be high enough to handle the common load on the 
server.
The default value for ThreadsPerChild is 64 when used with mpm_winnt 
The default value is 25 when used with other configurations such as worker

also from mladens discussion of connection_pool_size calcs based on Apache 
HTTPD Prefork vs Worker 
http://www.mail-archive.com/users@tomcat.apache.org/msg14767.html
Apache Prefork configuration
Apache 1.3 and Apache 2.x-prefork create a separate child process for
each client connection, meaning that if you have default
250 MaxClients, you can end up with MaxClients * connection_pool_size
connections to the Tomcat, that would in your case be 25.
(and in the case of ThreadsPerChild parameter 
MaxClients*64*connection_pool_size)

Apache Worker configuration
With worker mpm the connection_pool_size defaults to ThreadsPerChild,
that in the final gives the MaxClients connections to the Tomcat.
So the default value for connection_pool_size is always ThreadsPerChild
that with prefork mpm is by design always 1.
(in the case of ThreadsPerChild parameter not being null 
MaxClients*ThreadsPerChild)

HTH
Martin 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




Date: Mon, 18 May 2009 07:43:04 -0700
From: chetan_chh...@yahoo.com
Subject: Re: Tomcat not closing threads
To: users@tomcat.apache.org



Our network team is already engaged and looking into this. We had several 
instances of tomcats locking up today. I have attached one such thread dump 
here ..
 
Can some of you pls take a look and point me into the right direction?






From: rad muthu rmuth...@gmail.com
To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, May 13, 2009 8:05:08 PM
Subject: Re: Tomcat not closing threads

Chetan,


We had similar issue with Sun solaris and weblogic.

My system admin found out there is a socket read errors are going on . He
used snoop command in solaris. After tuning the TCP parameters the issue got
resolved.

You might also need to something like that.

Thanks
Krish



On Wed, May 13, 2009 at 11:57 AM, Chetan Chheda chetan_chh...@yahoo.comwrote:

 I guess I need to ask my question again. Im primarily an
 HP-UX
 administrator and recently inherited this web based application ...

 We are having some issues in accomodating additional user
 load/functionality. While a part of the team is looking at optimizing code,
 I am responsible for infrastructure componants.

 One particular focus area for me is the mod_jk and tomcat configurations.
 1. Last of April saw one of the tomcat's stop

Re: How to refer to file?

2009-05-18 Thread Juha Laiho

Hello,

by that logic, when you edit a file with Word, the default save
location should be the directory where the Word binary is located.

The current directory with servlet applications is rather weakly
defined - and for very strict adherence to servlet specification
you shouldn't even expect that the jsp files are located in a directory;
the application could be executing from an unexploded .war file
without any application-specific directory on the file system.

If you only need to read from the file, it would be preferred to
use ServlerContext.getResourceAsStream() instead. For read/write
access the servlet applications only guarantee an existence of
a temporary directory for the application; by breaking the pure
servlet application model, you can of course write/read a file
to whichever place you see fit (but don't expect any specific
default directory; instead use an explicit directory name whenever
opening a file. Even if your own code sets the default directory at
some point, it's completely possible that some other code in the
same process (3rd party library, servlet engine itself, whatever..)
can change the default directory without giving any notice.
-- 
..Juha

Dola Woolfe wrote:
 Thanks,
 But why would a %! % tag make a file default to the same dir as the .jsp 
 file.
 
 When I do
 %! String content = new java.io.File(Hi.txt).getAbsolutePath(); %, 
 
 I get:
 
 C:\dc\tomcat\bin\Hi.txt
 
 
 
 --- On Mon, 5/18/09, Steve Yates steven.ya...@springsource.com wrote:
 
 From: Steve Yates steven.ya...@springsource.com
 Subject: Re: How to refer to file?
 To: Tomcat Users List users@tomcat.apache.org
 Date: Monday, May 18, 2009, 1:28 AM
 Dola Woolfe wrote:
 Hi,

 Within a .jsp document, is there a way of referring to
 a file in same directory?
 For example, new java.io.File(ThisDir,
 FileName.txt).
 Thanks,

 Dola





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


 Hi Dola,

 Is this something you really need to do in the view layer
 like this? I
 am going to assume you have a really good reason to do this
 and say that
 it is possible using the same approach as you would declare
 a method in
 a .JSP file.

 This is slightly different to the scriptlet approach %
 % %= % etc

 You simply add a ! like so;

 %!
   *File myFile = new
 java.io.File();*
  
   public String methodDeclaration(.)
 {
   //DoSomething
   //... 
   return
 StringUtils.EmptyString();
  }
 %

 Don't forget to include the appropriate package as an
 import statement.

 RGS SY



 
 
   
 
 -
 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: Apache httpd vs Tomcat static content performance

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin,

On 5/18/2009 10:47 AM, Martin Gainty wrote:
 the apache httpd [crowd] may cry foul because you are testing with a
 prefork config instead of worker assuming you can scare up another
 processor

I'm happy to re-run the tests using a worker MPM as well. I'm already
testing lots of different TC connectors, so I may as well test the
worker MPM.

 is there a way to run the same httpd test suite with apache worker?

Sure. I've never configured an httpd for worker MPM, but this is
intended to be an out-of-the-box test anyway, so I don't need to know
anything about tweaking that type of worker :)

 data transfer rate refers to the achieved average net bit rate that
 is delivered to the application layer, exclusive of all protocol
 overhead, data packets retransmissions, etc. i would be interested to
 know how you detect protocol overhead and packet retransmits (to
 exclude for your data_transfer_rate calculations)

I don't. I'm allowing ApacheBench to count whatever it wants to count.
This is the full output of an 'ab' run in case you haven't seen it
before (example for my 1MiB test):

- - CUT -

Server Software:Apache-Coyote/1.1
Server Hostname:localhost
Server Port:8001

Document Path:  /tomcat/1MiB.bin
Document Length:1048576 bytes

Concurrency Level:  1
Time taken for tests:   609.926 seconds
Complete requests:  10
Failed requests:0
Write errors:   0
Total transferred:  10488220 bytes
HTML transferred:   10485760 bytes
Requests per second:163.95 [#/sec] (mean)
Time per request:   6.099 [ms] (mean)
Time per request:   6.099 [ms] (mean, across all concurrent requests)
Transfer rate:  167928.56 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:00   0.4  0 112
Processing: 56   2.6  6 525
Waiting:00   0.1  0  31
Total:  66   2.6  6 525

Percentage of the requests served within a certain time (ms)
  50%  6
  66%  6
  75%  6
  80%  6
  90%  6
  95%  6
  98%  7
  99%  7
 100%525 (longest request)

- - CUT -

ApacheBench indicates that 10488220 bytes were transferred but that
10485760 (2460 fewer) HTML bytes were transferred. Those extra
bytes are most likely the HTTP headers. There are no counts for TCP
handshake, ACK packets, or any other low-level protocol statistics, but
they would be the same for any software since the kernel is taking care
of all of that detail in any case. I'm not comparing OSs, here: I'm
comparing HTTP server software :)

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

iEYEARECAAYFAkoRgEUACgkQ9CaO5/Lv0PC4FgCgq0XG6nG/JYn8nqqCuLfLn1e0
S7sAn0daa0Hah643MolLVUYxc8CixPjJ
=Oexn
-END PGP SIGNATURE-

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

Re: Apache httpd vs Tomcat static content performance

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 5/18/2009 11:23 AM, Christopher Schultz wrote:
 Chuck,

Er, Peter. Sorry 'bout that.

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

iEYEARECAAYFAkoRgJYACgkQ9CaO5/Lv0PBLkQCguzyGfgiEMNw+6lbR+Z2IPkyn
sg8An1rHa5Rx4MadgXuH9X8kCadz5b5g
=T8h4
-END PGP SIGNATURE-

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

RE: Apache httpd vs Tomcat static content performance

2009-05-18 Thread Peter Crowther

 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 I suppose I could gauge each test so it would take (roughly) a certain
 amount of time (say, 10 minutes). At least then I'd know how long the
 entire battery would take :)

I think that's probably a better approach.

 Okay. My original test plan included concurrencies of 1, 2, 4, 8, and
 16. I think I'll just do 1 and 16 and maybe another one if I get the
 time. Maybe I should just get a faster server :)

1, 4, 16 would be interesting - and if you run for fixed time rather than fixed 
number of requests, you might be able to afford to do this.

 That's a good question... if the disk can't read the data any faster,
 than the server can't serve the bytes any faster (unless caching is
 being used, I suppose, but this is supposed to be
 out-of-the-box config).

You'd hope your underlying OS (Gentoo, I assume from your other message) would 
cache the file!

 Since this is a relatively old server (1500MHz 32-bit AMD Athlon), I'm
 surely being limited by just about everything except memory
 capacity (it
 doesn't take much memory to serve static content). I can easily get
 memory timing information, and I suspect my memory timing will
 significantly beat the throughput of the TCP stack (shared memory be
 damned). I can also benchmark my disk I suppose. Since I already have
 the transfer rates for the HTTP responses, I can simply see if the
 hardware is significantly faster than the server so rule-out any real
 hardware difficulties.

As a rough first cut, vmstat 5 and watch the numbers ;-).  iostat too, if you 
can.  If CPU isn't pegged at 100% and the disk isn't at full capacity, that's 
an interesting result as it implies the box has spare capacity and there's 
contention elsewhere - often lock contention, as David Kerber has recently seen!

It just seems a shame to waste the opportunity to gather information about 
*what* the rate limiter is, as well as at what point you get to the limit.

- Peter

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

RE: Apache httpd vs Tomcat static content performance

2009-05-18 Thread Robin Wilson

I'm curious by your comment that Coyote/APR is performing on par with httpd, 
from the results in your first message I saw it was a pretty big difference. Or 
are you saying that wasn't using APR?

Also, I'd be curious about the big disparity between the 16MiB files and the 
other 1MiB-32MiB files... It looks like all of them are relatively consistent 
at the KiB/sec rates you show - but suddenly there's a huge burst of speed on 
the 16MiB file (for httpd). So I'd be really curious to understand why the 
large disparity is evident there.

I'd like to see your results using TC6.0.18 and APR as well.

Also, just idle curiosity - does HTTPS affect the performance difference 
between the two at all? Even though these are static files, it would probably 
show if there are any SSL handling differences between tomcat and apache.

--
Robin D. Wilson
Director of Web Development
KingsIsle Entertainment, Inc.
WORK: 512-623-5913
CELL: 512-426-3929
www.KingsIsle.com



-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Monday, May 18, 2009 10:24 AM
To: Tomcat Users List
Subject: Re: Apache httpd vs Tomcat static content performance

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

On 5/18/2009 10:33 AM, Peter Crowther wrote:
 From: Christopher Schultz [mailto:ch...@christopherschultz.net] 1.
 Is the number of requests (100, sufficient? It seems to take 
 forever on this machine... my Coyote tests took longer than 
 overnight.
 
 You want enough tests that they're sensitive to statistically 
 significant differences that you're interested in finding. The tests 
 shouldn't be dominated by end effects - startup and shutdown. I'd be 
 more inclined to run *multiple* tests - 3 is about the minimum - to
 make sure that your single test hasn't been messed up by something 
 unexpected. I'd expect a few minutes per test to be enough to ignore
 end effects; I'd be far more inclined to run 10 2-minute tests than
 1 20-minute test, for example.

Well, these tests are taking a long time. The size of each file
obviously has an effect on the time it takes to serve 100,000 requests.
I'm running my Coyote/APR tests, now (which I'll throw out, because its
an old version of tcnative AND my site is actively being used right now)
and the 4KiB tests took 54.987 seconds while the 512KiB tests took
344.414 seconds. (I'm happy to say that Coyote/APR is performing on par
with httpd which seems pretty obvious since they should be running
roughly the same code).

I suppose I could gauge each test so it would take (roughly) a certain
amount of time (say, 10 minutes). At least then I'd know how long the
entire battery would take :)

 2. Is a concurrency of 1 okay? I thought about it and testing the 
 ability of the OS to schedule processes and threads doesn't seem 
 like it adds anything to the data.
 
 Depends. *Exactly* what are you testing? If it's who can serve the 
 most bytes per second / requests per second, a concurrency of 1
 isn't appropriate - you want to see what happens as you approach
 saturation, which is unlikely to happen with a single thread. If it's
 who can serve load without horrible lock contention in the system,
 same answer.

Okay. My original test plan included concurrencies of 1, 2, 4, 8, and
16. I think I'll just do 1 and 16 and maybe another one if I get the
time. Maybe I should just get a faster server :)

 Below is the data I've collected so far. I'll publish everything on
 my blog, including graphs, etc. once it's finished. (Strange that
 httpd dramatically increased its transfer rate when requesting the 
 16MiB file!)
 
 Looks interesting.  Is there any way of finding out what the
 rate-limiting factor is in each case - CPU, memory bandwidth, memory
 capacity, disk bandwidth?

That's a good question... if the disk can't read the data any faster,
than the server can't serve the bytes any faster (unless caching is
being used, I suppose, but this is supposed to be out-of-the-box config).

Since this is a relatively old server (1500MHz 32-bit AMD Athlon), I'm
surely being limited by just about everything except memory capacity (it
doesn't take much memory to serve static content). I can easily get
memory timing information, and I suspect my memory timing will
significantly beat the throughput of the TCP stack (shared memory be
damned). I can also benchmark my disk I suppose. Since I already have
the transfer rates for the HTTP responses, I can simply see if the
hardware is significantly faster than the server so rule-out any real
hardware difficulties.

On the other hand, since both servers are running on the same hardware,
the playing-field is at least level: they are already performing
differently from each other, so I think I have a decent basis for
comparison even without doing a detailed hardware analysis.

Thanks for your thoughts,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

Re: Tomcat not closing threads

So what you are suggesting is my mod_jk and tomcat parameters in server.xml are 
messed up .. 

Here is my current setup I have one apache load balancing to 2 tomcat workers
Maxclients = 512 
ThreadsPerChild = 256
Connection_pool_size = 256 
Tomcat MaxThreads = 150 

I will suggest my team to change this to ... 
connection_pool_size = 120  - which means that I will have 120*2(2 apache 
server procs) = 240 threads per tomcat 
Tomcat maxthreads = 300

So out of total 512 worker threads , a max of 480 threads will be used by 
mod_jk leaving the rest for serving static content. 

is my math correct? 

Thanks!




From: Martin Gainty mgai...@hotmail.com
To: Tomcat Users List users@tomcat.apache.org
Sent: Monday, May 18, 2009 11:23:58 AM
Subject: RE: Tomcat not closing threads


some documentation:

http://httpd.apache.org/docs/2.0/mod/mpm_common.html
MaxClients:
The MaxClients directive sets the limit on the number of simultaneous requests 
that will be served. 
Any connection attempts over the MaxClients limit will normally be queued, up 
to a number based on the ListenBacklog directive. 
Once a child process is freed at the end of a different request, the connection 
will then be serviced.
For non-threaded servers (i.e., prefork), MaxClients translates into the 
maximum number of child processes that will be launched to serve requests. The 
default value is 256; to increase it, you must also raise ServerLimit.
For threaded and hybrid servers (e.g. beos or worker) MaxClients restricts the 
total number of threads that will be available to serve clients. 
The default value for beos is 50. 
For hybrid MPMs (your situation) the default value is 16 (ServerLimit) 
multiplied by the value of ThreadsPerChild. 
Therefore, to increase MaxClients to a value that requires more than 16 
processes, you must also raise ServerLimit.

ThreadsPerChild
This directive sets the number of threads created by each child process.
The child creates these threads at startup and never creates more. 
If using an MPM like mpm_winnt, where there is only one child process, this 
number should be high enough to handle the entire load of the server. 
If using an MPM like worker, where there are multiple child processes, the 
total number of threads should be high enough to handle the common load on the 
server.
The default value for ThreadsPerChild is 64 when used with mpm_winnt 
The default value is 25 when used with other configurations such as worker

also from mladens discussion of connection_pool_size calcs based on Apache 
HTTPD Prefork vs Worker 
http://www.mail-archive.com/users@tomcat.apache.org/msg14767.html
Apache Prefork configuration
Apache 1.3 and Apache 2.x-prefork create a separate child process for
each client connection, meaning that if you have default
250 MaxClients, you can end up with MaxClients * connection_pool_size
connections to the Tomcat, that would in your case be 25.
(and in the case of ThreadsPerChild parameter 
MaxClients*64*connection_pool_size)

Apache Worker configuration
With worker mpm the connection_pool_size defaults to ThreadsPerChild,
that in the final gives the MaxClients connections to the Tomcat.
So the default value for connection_pool_size is always ThreadsPerChild
that with prefork mpm is by design always 1.
(in the case of ThreadsPerChild parameter not being null 
MaxClients*ThreadsPerChild)

HTH
Martin 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




Date: Mon, 18 May 2009 07:43:04 -0700
From: chetan_chh...@yahoo.com
Subject: Re: Tomcat not closing threads
To: users@tomcat.apache.org



Our network team is already engaged and looking into this. We had several 
instances of tomcats locking up today. I have attached one such thread dump 
here ..

Can some of you pls take a look and point me into the right direction?
    





From: rad muthu rmuth...@gmail.com
To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, May 13, 2009 8:05:08 PM
Subject: Re: Tomcat not closing

Re: Apache httpd vs Tomcat static content performance

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

On 5/18/2009 10:32 AM, Caldarale, Charles R wrote:
 From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
 Subject: Apache httpd vs Tomcat static content performance

 I will be comparing an out-of-the-box prefork MPM httpd 2.2.10 
 configuration against an out-of-the-box Tomcat 5.5.26 Coyote, APR,
 and APR without sendfile configurations (I didn't realize until
 after I started my Coyote tests that NIO is only available in
 TC6.0, so I'll be doing my NIO tests on 6.0).

 Better to do it all with Tomcat 6.0; no point in benchmarking levels
 that are under limited development.

Fair enough. I should probably run against httpd 2.2.11 as well.

 What JVM are you using?  I'd recommend a 1.6, preferably in server
 mode.  What's the heap size?  Any evidence of GC going on?

I could instrument the JVM but is it really worth it?

My JVM is:
java version 1.6.0_13
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing)

I have specified no heap settings, so I'm getting the default for this
mode, which appears to be a 64MiB heap, of which 50MiB has been
allocated. The heap usage appears to float around 60% capacity (32MiB).

 What hardware do you have?  I saw no mention of CPU type or RAM or
 disk.

I'll publish full hardware specs with a full set of data, but quickly:
1500MHz AMD Athlon 1700+, 1GiB memory, 987997KiB swap, Seagate ST380013A
IDE disk, ext3fs. OS is GNU/Linux kernel 2.6.14. Apache httpd 2.2.10 was
compiled locally using CFLAGS -O2 -march=athlon-xp -fomit-frame-pointer.

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

iEYEARECAAYFAkoRhFAACgkQ9CaO5/Lv0PAoowCgmoqlqoaMJYRJCv4lUOQvYWju
h00AoID5/AOiAJ2ivgpI5aiXiNfuiNRm
=u9b6
-END PGP SIGNATURE-

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

Re: Trouble building tcnative

2009-05-18 Thread Juha Laiho

Christopher Schultz wrote:
 I've never built tcnative before, but I'm no stranger to the standard
 UNIX source package build process. I'm having a bit of difficulty
 building this.
...

 ...and this is where things fall apart for me. Here's the output of
 configure (apologies for any bad line wrapping):
 
 $ ./configure --with-apr=/usr/bin/apr-1-config
 checking build system type... i686-pc-linux-gnu
...
 ./configure: line 4315: APR_BUILD_DIR: command not found
 ./configure: line 4316: APR_INCLUDES: command not found
 ...
 
 This is followed by hundreds of lines of line xyz: [whatever]: command
 not found.

That might be an issue with either the shell you're using to start
configure, or the default shell for your account. But then, this
is just a quick guess. You might want (or not want, actually, but..)
to look at perhaps the ten or so lines before 4315 in the configure
script. It may also be that the script itself is somehow broken.
-- 
..Juha

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

Re: Apache httpd vs Tomcat static content performance

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter,

On 5/18/2009 11:37 AM, Peter Crowther wrote:
 I suppose I could gauge each test so it would take (roughly) a certain
  amount of time (say, 10 minutes). At least then I'd know how long the
  entire battery would take :)
 
 I think that's probably a better approach.

Hey, it looks like the -t switch will allow me to simply get as many
requests into, say, 10 minutes as possible. That would be great to know
how long the tests will take :) I think I'll modify my testing script
and re-sample, especially since I'm likely to be upgrading everything,
anyway.

 As a rough first cut, vmstat 5 and watch the numbers ;-).  iostat
 too, if you can.  If CPU isn't pegged at 100% and the disk isn't at
 full capacity, that's an interesting result as it implies the box has
 spare capacity and there's contention elsewhere - often lock
 contention, as David Kerber has recently seen!

I wouldn't expect 100% CPU usage. I would expect that most of the wait
time is pushing the bytes through the NIC. Right now, my throw-away test
against TC5.5/APR is showing java using between 65-70% of the CPU.

 It just seems a shame to waste the opportunity to gather information
 about *what* the rate limiter is, as well as at what point you get to
 the limit.

Gotcha. I have no experience with vmstat and iostat, so I'd mostly be
collecting the data for others to peruse. But, I'm happy to do it
(especially if it won't favor one piece of software over the other
merely by /running/).

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

iEYEARECAAYFAkoRhz4ACgkQ9CaO5/Lv0PAb5wCdEAJjWw/qVTOIfAGluXmG0EOy
OIMAoJI1WSrsAyxLP8yguQCb5S/7f1gD
=9y3H
-END PGP SIGNATURE-

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

Re: Apache httpd vs Tomcat static content performance

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robin,

On 5/18/2009 11:35 AM, Robin Wilson wrote:
 I'm curious by your comment that Coyote/APR is performing on par with
 httpd, from the results in your first message I saw it was a pretty
 big difference. Or are you saying that wasn't using APR?

Right. Sorry if I wasn't clear: the first test (already published in a
previous message) was using the standard, non-APR Coyote connector. I'm
currently running a test which shows that APR brings Tomcat back into
contention. Here is the full set of numbers as far as the test has run:

File Size   Apache httpdTC5.5 CoyoteTC 5.5 APR
4kiB6215.20 5467.43 7700.63
8kiB11630.179732.60 14054.87
16kiB   21271.9216266.6623027.55
32kiB   38257.7727530.7536269.42
64kiB   63729.1241946.4559215.64
128kiB  91768.2356000.1990059.61
256kiB  126919.12   72062.84124735.84
512kiB  160506.81   66654.86148727.29
1MiB180850.63   72533.92167928.56
2MiB185157.29   75957.71174630.72
4MiB185262.91   77969.20(data not yet available)
8MiB185152.66   79075.54(data not yet available)
16MiB   256399.66   80364.26(data not yet available)
32MiB   189933.50   80243.41(data not yet available)

 Also, I'd be curious about the big disparity between the 16MiB files
 and the other 1MiB-32MiB files... It looks like all of them are
 relatively consistent at the KiB/sec rates you show - but suddenly
 there's a huge burst of speed on the 16MiB file (for httpd). So I'd
 be really curious to understand why the large disparity is evident
 there.

I agree. I'll be re-running the tests against httpd, anyway, so maybe
we'll see it happen again. If anything, I would have expected to see a
sharp /decrease/ in transfer rate at some point (like a batch job ran in
the middle of the night or something). Observing the opposite is
baffling to me.

 I'd like to see your results using TC6.0.18 and APR as well.

Patience! I'll publish everything once I've got it.

 Also, just idle curiosity - does HTTPS affect the performance
 difference between the two at all? Even though these are static
 files, it would probably show if there are any SSL handling
 differences between tomcat and apache.

I'm sure it would. Once I have these stats, I could publish another set
based upon HTTPS. The APR documentation suggests that if you want decent
HTTPS performance in Tomcat, you should use APR instead of the Java SSL
libraries. So, I suspect non-APR SSL in Tomcat to perform poorly in
comparison to Apache httpd.

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

iEYEARECAAYFAkoRiFIACgkQ9CaO5/Lv0PBBlACgtFiXzCUZo07QwaIiKTRV5UE1
59QAoLZxKky9P0OqEFgkvB59qvRBpfL2
=LNpJ
-END PGP SIGNATURE-

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

Re: MAX Simultaneous connections with Tomcat on Windows XP Pro

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter,

On 5/18/2009 3:19 AM, Peter Crowther wrote:
 From: Arijit Sarkar Job Gmail [mailto:arijit.k.sar...@gmail.com] So
 If I have an web application deployed on tomcat and windows XP
 pro, theoretically, unlimited users can connect to the application 
 simultaneously? Tomcat or Windows XP does not place any limits to
 that?
 
 There are no limits imposed by XP's license - XP's 10-connection
 limit applies only to it acting as a SMB server, and doesn't affect
 anything else.

I have seen claims that it also affects IIS connections. Is it just that
anything server-related that Microsoft sells is limited to 10 (total?
per package?) connections when running on a non-server-branded version
of Windows?

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

iEYEARECAAYFAkoRiTcACgkQ9CaO5/Lv0PBTmACeIuZWZsFUnfQK0dft1GNgYE9z
bQYAn3GvzfJzXgMoFv2ExYbk8se9fUcf
=mKM3
-END PGP SIGNATURE-

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

Re: Apache httpd vs Tomcat static content performance

2009-05-18 Thread David kerber


Peter Crowther wrote:

...

As a rough first cut, vmstat 5 and watch the numbers ;-).  iostat too, if you 
can.  If CPU isn't pegged at 100% and the disk isn't at full capacity, that's 
an interesting result as it implies the box has spare capacity and there's 
contention elsewhere - often lock contention, as David Kerber has recently seen!

  
Indeed!  Getting rid of the extra locking took care of about 98% of the 
issues, and changing to the Server jvm got me to over 99%.


D



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

Re: Tomcat not closing threads

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chetan,

On 5/18/2009 10:43 AM, Chetan Chheda wrote:
 Our network team is already engaged and looking into this. We had
 several instances of tomcats locking up today. I have attached one such
 thread dump here ..

It looks like all your request processors are waiting for data to be
read from the client. Can you post your current:

workers.properties
httpd.conf (portions relevant to the worker MPM and mod_jk)
Connector

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

iEYEARECAAYFAkoRik4ACgkQ9CaO5/Lv0PDktACfZRY7Eu5R/0nvnyGdOiXD2tID
9RQAoKCgluYtV8ht5/DAvWc1nP4b+yeQ
=UycA
-END PGP SIGNATURE-

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

Re: MAX Simultaneous connections with Tomcat on Windows XP Pro

2009-05-18 Thread David kerber


Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter,

On 5/18/2009 3:19 AM, Peter Crowther wrote:
  

From: Arijit Sarkar Job Gmail [mailto:arijit.k.sar...@gmail.com] So
If I have an web application deployed on tomcat and windows XP
pro, theoretically, unlimited users can connect to the application 
simultaneously? Tomcat or Windows XP does not place any limits to

that?
  

There are no limits imposed by XP's license - XP's 10-connection
limit applies only to it acting as a SMB server, and doesn't affect
anything else.



I have seen claims that it also affects IIS connections. Is it just that
anything server-related that Microsoft sells is limited to 10 (total?
per package?) connections when running on a non-server-branded version
of Windows?
  
Yes.  We have run into that issue ourselves.  It's handled the same as 
if a server had been trying to handle more connections than it was 
licensed for.  This definitely includes IIS clients and SMB shares.  I 
don't know if it also includes microsoft ftp and e-mail connections, but 
it may (probably does, in fact).


D



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

mod_jk emptysessionpath and jvmroute replacement

2009-05-18 Thread jhoare

Hi, our app currently relies on using the attribute 
emptysessionpath=true on the ajp connector due to having most of our 
urls not containing the context path of our web app. We are having 
trouble with the jvmroute switching as the Tomcat code doesn't appear to 
check if the jvmroute is valid for that node? I noticed in the 
org.apache.catalina.session.ManagerBase there is some code that is 
commented out, which would fix the route replacement.

We don't currently use clustering so we can't use the 
org.apache.catalina.ha.session.JvmRouteBinderValve, would I need to 
raise a change request to get the code below in the next release? Or is 
there any other options available to us?

Thanks

code from ManagerBase:

if (sessionId == null) {
sessionId = generateSessionId();
// FIXME WHy we need no duplication check?
/*
 synchronized (sessions) {
while (sessions.get(sessionId) != null) { // Guarantee
// uniqueness
duplicates++;
sessionId = generateSessionId();
}
}
*/
   
// FIXME: Code to be used in case route replacement is needed
/*
} else {
String jvmRoute = getJvmRoute();
if (getJvmRoute() != null) {
String requestJvmRoute = null;
int index = sessionId.indexOf(.);
if (index  0) {
requestJvmRoute = sessionId
.substring(index + 1, sessionId.length());
}
if (requestJvmRoute != null  
!requestJvmRoute.equals(jvmRoute)) {
sessionId = sessionId.substring(0, index) + . + 
jvmRoute;
}
}
*/
}




Stella McCartney's exclusive collection for NET-A-PORTER.COM has arrived! Watch 
 shop it here: www.net-a-porter.com/stella
__

CONFIDENTIALITY NOTICE
The information in this email is confidential and is intended solely for the 
addressee. Access to this email by anyone else is unauthorised. If you are not 
the intended recipient, you must not read, use or disseminate the information. 
Any views expressed in this message are those of the individual sender, except 
where the sender specifically states them to be the views of Net a Porter Ltd. 

Net A Porter Ltd is a company registered in England  Wales Number: 3820604 
Registered Office: The Dome, Whiteleys Centre, 151 Queensway, London, W2 4YN.
_

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

Re: Trouble building tcnative

On 18.05.2009 18:03, Juha Laiho wrote:
 Christopher Schultz wrote:
 I've never built tcnative before, but I'm no stranger to the standard
 UNIX source package build process. I'm having a bit of difficulty
 building this.
 ...
 
 ...and this is where things fall apart for me. Here's the output of
 configure (apologies for any bad line wrapping):

 $ ./configure --with-apr=/usr/bin/apr-1-config
 checking build system type... i686-pc-linux-gnu
 ...
 ./configure: line 4315: APR_BUILD_DIR: command not found
 ./configure: line 4316: APR_INCLUDES: command not found
 ...

 This is followed by hundreds of lines of line xyz: [whatever]: command
 not found.
 
 That might be an issue with either the shell you're using to start
 configure, or the default shell for your account. But then, this
 is just a quick guess. You might want (or not want, actually, but..)
 to look at perhaps the ten or so lines before 4315 in the configure
 script. It may also be that the script itself is somehow broken.

There was a bug in tcnative 1.1.12 with this symptom:

IFS problem in native/build/tcnative.m4 (rjung) 

It's likely you hit it. I suggest using the latest tcnative version,
because there were also a couple of functional bugs fixed. On

http://tomcat.apache.org/download-native.cgi

you'll find a download of 1.1.16, which builds exactly like the 1.1.12
you were already trying to use (configure et.al.).

Regards,

Rainer

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

running tomcat5 -- as a service under 64-bit windows?

2009-05-18 Thread w...@serensoft.com

Hi folks --

Short version: how to get Tomcat5 to run as a service under 64-bit Windows 2003?

Long version:

Okay, we've got Tomcat5 running from the command-line within 64-bit
Windows 2003 Enterprise (and cannot use tomcat 6/java 6 for our
project) -- and now we're working to get it running as a service...

We've replaced the original tomcat5.exe and tomcat5w.exe with the ones at
http://svn.apache.org/viewvc/tomcat/connectors/trunk/procrun/bin/amd64/
as directed from
http://www.nabble.com/running-tomcat-5.5-as-a-service-on-64bit-windows-td6821449.html

And then command line 'service install' appears to work (it shows up
in admin tools  services) but the service won't start: it tries for a
while (netstat -nab shows it's running for a spell), but it quietly
gives up. tomcat/logs/stderr* does contain some text, but there's no
catalina.out, and start  admin tools  component services  events
doesn't give up any evidence either.

Plus, the mofidied/64-bit-savvy tomcat5w.exe which is supposed to set
parameters for the service, complains that 'tomcat5' doesn't exist.

Ideas?

-- 
will trillich
Our only real economic security lies in our power to meet human
needs. -- S.Covey, the 8th Habit

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

RE: Trouble building tcnative

dl/l tomcat-native-1.1.16-win32-src from
http://tomcat.apache.org/download-native.cgi
Cannot open include file: 'apr.h': No such file or directory?
also i did'nt see makefile ?

Martin
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Date: Mon, 18 May 2009 19:11:10 +0200
From: rainer.j...@kippdata.de
To: users@tomcat.apache.org
Subject: Re: Trouble building tcnative

On 18.05.2009 18:03, Juha Laiho wrote:
Christopher Schultz wrote:
I've never built tcnative before, but I'm no stranger to the standard
UNIX source package build process. I'm having a bit of difficulty
building this.
...

...and this is where things fall apart for me. Here's the output of
configure (apologies for any bad line wrapping):

$ ./configure --with-apr=/usr/bin/apr-1-config
checking build system type... i686-pc-linux-gnu
...
./configure: line 4315: APR_BUILD_DIR: command not found
./configure: line 4316: APR_INCLUDES: command not found
...

This is followed by hundreds of lines of line xyz: [whatever]: command
not found.

That might be an issue with either the shell you're using to start
configure, or the default shell for your account. But then, this
is just a quick guess. You might want (or not want, actually, but..)
to look at perhaps the ten or so lines before 4315 in the configure
script. It may also be that the script itself is somehow broken.

There was a bug in tcnative 1.1.12 with this symptom:

IFS problem in native/build/tcnative.m4 (rjung)

It's likely you hit it. I suggest using the latest tcnative version,
because there were also a couple of functional bugs fixed. On

http://tomcat.apache.org/download-native.cgi

you'll find a download of 1.1.16, which builds exactly like the 1.1.12
you were already trying to use (configure et.al.).

Regards,

Rainer

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

_
Hotmail® has a new way to see what's up with your friends.
http://windowslive.com/Tutorial/Hotmail/WhatsNew?ocid=TXT_TAGLM_WL_HM_Tutorial_WhatsNew1_052009

RE: Running out of tomcat threads - why many threads in RUNNABLE stage even with no activity

Hi Chris,

Thanks for your reply.

 
 On 5/13/2009 5:28 PM, Pantvaidya, Vishwajit wrote:
  My setup is tomcat 5.5.17 + mod_jk 1.2.15 + httpd 2.2.2. I am using
  AJP1.3.
 
 Old versions of everything. Consider upgrading?
 
[Pantvaidya, Vishwajit] Yes, sure - we will upgrade at some point of time. But 
since upgrading all our servers will be some work, that may not happen right 
away.


  Every 2-3 days with no major load, tomcat throws the error: SEVERE:
  All threads (200) are currently busy, waiting...
 
  I have been monitoring my tomcat TP-Processor thread behavior over
  extended time intervals and observe that: - even when there is no
  activity on the server, several TP-Processor threads are in RUNNABLE
  state while few are in WAITING state
 
 It appears that you have 200 threads available. How many (on average)
 are RUNNABLE versus WAITING? (The two counts should add to 200, unless
 there's some other state (BLOCKED?) that the threads can be in, but you
 didn't mention any other states).

[Pantvaidya, Vishwajit] Here are figures from 3 of the servers which have not 
yet run out of threads (so the thread count does not add up to 200). I have 
taken these late at night when no users are present, so I was expecting all 
threads to be Waiting for tomcat thread-pool.

1. Total TP-Processor threads 48, Waiting 46, Runnable 2
2. Total TP-Processor threads 40, Waiting 29, Runnable 11
3. Total TP-Processor threads 120, Waiting 7, Runnable 113


 
  - RUNNABLE threads stack trace shows java.lang.Thread.State:
  RUNNABLE at java.net.SocketInputStream.socketRead0(Native
  Method)...
 
 This indicates that the client has not yet disconnected, and is probably
 still sending data. If there were not any data waiting, the state should
 be BLOCKED.
 
  - WAITING thread stack trace shows java.lang.Thread.State: WAITING
  on
  org.apache.tomcat.util.threads.threadpool$controlrunna...@53533c55
 
 These are idle threads.
 
  - tomcat adds 4 new TP-Processor threads when a request comes in and
  it can find no WAITING threads
 
 Wow, 4 new threads? That seems like 3 too many...

[Pantvaidya, Vishwajit] Do you think this could be because of the application? 
I was under the impression that there is some tomcat config parameter that 
controls this - which was set to 4.

 
  So I conclude that my tomcat is running out of threads due to many
  threads being in RUNNABLE state when actually they should be in
  WAITING state. Is that happening because of the socket_keepalive in
  my workers.properties shown below?
 
 worker.socket_keepalive just keeps the connection between Apache httpd
 and Tomcat alive in case you have an overzealous firewall that closes
 inactive connections. The request processor shouldn't be affected by
 this setting.
 
  Why are threads added in bunches of 4 - is there any way to configure
  this?
 
  My workers config is:
 
  Worker...type=ajp13 Worker...cachesize=10
 
 Are you using the prefork MPM? If so, cachesize should be /1/.
 

[Pantvaidya, Vishwajit] Could you please elaborate. What is the prefork MPM?


  Worker...cache_timeout=600 Worker...socket_keepalive=1
  Worker...recycle_timeout=300
 
 Are these timeouts necessary? Why not simply let the connections stay
 alive all the time?
 
[Pantvaidya, Vishwajit] Sure we could. But for any production change, I would 
have to offer a good enough reason.

  Earlier posts related to this issue on the list seem to recommend
  tweaking: - several timeouts - JkOptions +DisableReuse
 
 This will require that every incoming HTTP connection opens up a new
 ajp13 connection to Tomcat. Your performance will totally suck if you
 enable this. But if it's the only way for you to get your application
 working properly, then I guess you'll have to do it. I suspect you /will
 not/ have to enable +DisableReuse.
 
[Pantvaidya, Vishwajit] I was seeing earlier posts on this list mention some 
disagreement on the performance impact of setting +DisableReuse. Otherwise I 
would not even think of this.

By the way, the above 3 figures I provided are without connectiontimeout being 
set for Connector element in server.xml.

- Vish.

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

Re: Tomcat not closing threads

HTTPd.conf : 
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 30 

IfModule worker.c
ThreadLimit    512
StartServers   100 
MaxClients 512 
MinSpareThreads    129 
MaxSpareThreads    256 
ThreadsPerChild    256 
MaxRequestsPerChild  0
/IfModule

Workers.properties: 
njipuplmapp01:/opt/hpws/apache/conf#cat workers.properties
ps=/
workers.tomcat_home=/coach/app/ptc/tomcat1
worker.list=ajp13App11,ajp13App12,loadbalancer,mystatus
worker.ajp13App11.port=8010
worker.ajp13App11.host=localhost
worker.ajp13App11.type=ajp13
worker.ajp13App11.lbfactor=1
worker.ajp13App11.cache_timeout=900
worker.ajp13App11.socket_timeout=0
worker.ajp13App11.retries=3
worker.ajp13App11.recycle_timeout=900

worker.ajp13App12.port=8011
worker.ajp13App12.host=localhost
worker.ajp13App12.type=ajp13
worker.ajp13App12.lbfactor=1
worker.ajp13App12.cache_timeout=900
worker.ajp13App12.socket_timeout=0
worker.ajp13App12.retries=3
worker.ajp13App12.recycle_timeout=900

worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=ajp13App11,ajp13App12
worker.loadbalancer.method=Request
worker.loadbalancer.sticky_session=true

worker.inprocess.class_path=$(workers.tomcat_home)$(ps)lib$(ps)tomcat.jar
worker.inprocess.cmd_line=start
worker.inprocess.stdout=$(workers.tomcat_home)$(ps)logs$(ps)inprocess.stdout
worker.inprocess.stderr=$(workers.tomcat_home)$(ps)logs$(ps)inprocess.stderr

worker.mystatus.type=status
worker.mystatus.mount=/admin/status/jk

mod_jk 
# Configure mod_jk for basic operation
IfModule mod_jk.c
  JkWorkersFile conf/workers.properties
  JkLogFile logs/mod_jk.log
  JkLogLevel info
  JkShmFile logs/JkShmFile.log
  
  # Must use this for proper % escaping (cannot use with Tomcat 3.2.x)
  JkOptions +ForwardURIEscaped
  # Uncomment the line below once HP builds with mod_jk 1.2.13 or
  # higher to ensure that the 'X-Do-not-compress-this' header
  # behaves as expected.
  #JkOptions +FlushPackets
  
  # Mount all JSP pages with our default worker
  JkMount /*.jsp loadbalancer
  JkMount /*.jsp/* loadbalancer
/IfModule

Connector :
    Connector acceptCount=100 connectionTimeout=2 
disableUploadTimeout=true port=8082 redirectPort=8445 
maxSpareThreads=75 maxThreads=150 minSpareThreads=25
    /Connector
    Connector URIEncoding=UTF-8 acceptCount=100 debug=1 port=8012 
protocol=AJP/1.3 
protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler 
redirectPort=8445 tomcatAuthentication=false useBodyEncodingForURI=true
    /Connector



From: Christopher Schultz ch...@christopherschultz.net
To: Tomcat Users List users@tomcat.apache.org
Sent: Monday, May 18, 2009 12:18:22 PM
Subject: Re: Tomcat not closing threads

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chetan,

On 5/18/2009 10:43 AM, Chetan Chheda wrote:
 Our network team is already engaged and looking into this. We had
 several instances of tomcats locking up today. I have attached one such
 thread dump here ..

It looks like all your request processors are waiting for data to be
read from the client. Can you post your current:

workers.properties
httpd.conf (portions relevant to the worker MPM and mod_jk)
Connector

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

iEYEARECAAYFAkoRik4ACgkQ9CaO5/Lv0PDktACfZRY7Eu5R/0nvnyGdOiXD2tID
9RQAoKCgluYtV8ht5/DAvWc1nP4b+yeQ
=UycA
-END PGP SIGNATURE-

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

Problems configuring mod_jk

2009-05-18 Thread Gregor Schneider

Hi guys,

I'm about to update an old Tomcat-instance (5.5.quite_old) to the
latest 5.5, also I'm about to update an outdated mod_jk to the latest
version.

The old config of mod_jk had quite some depricated directions
included, so I changed them (opefully) according to the doc I found
here:http://tomcat.apache.org/connectors-doc/reference/workers.html

However, when I check the logs from mod_jk, I always get the following
error-messages (multiple times, I guess it's one for every virtual
host in Apache HTTPD):

[2009-05-18 19:34:44][18754:3078399680] [error]
uri_worker_map_ext::jk_uri_worker_map.c (506): Could not find worker
with name 'worker' in uri map post proces
sing.

However, I do not see where I defined a worker with the name worker.

All vhost-definitions within Apache are alike when it comes to the
jk-specs, thus I'm just posting a sample vhost-definition:

VirtualHost *:443
[ ...]

JkMount /SingleSignOnCLUE/* worker
JkMount /LoginData/* worker
JkMount /j_security_check worker
JkMount /IndexCLUE/* worker
JkMount /BMIWizardCLUE/* worker
JkMount /RRWizardCLUE/* worker
JkMount /DiabetesCLUE/* worker
JkMount /HyperlipCLUE/* worker
JkMount /ForeignTravelCLUE/* worker
JkMount /MartialArtsCLUE/* worker
#
JkRequestLogFormat %b %m %q %s %T

[ ...]
/VirtualHost

My jk.conf:

JkWorkersFile /etc/apache2/workers.properties
JkLogFile |/usr/bin/cronolog -S/var/log/apache2/mod_jk.log
/var/log/apache2/%Y/%m/mod_jk-%d.log
JkLogLevel info
JkLogStampFormat [%F %T]


And here come my workers.properties:

# workers.properties - ajp13
#
# List workers
worker.list=wrkr
# Define wrkr
worker.wrkr.port=8009
worker.wrkr.host=127.0.0.1
worker.wrkr.type=ajp13
worker.wrkr.connection_pool_size=30
worker.wrkr.connection_pool_timeout=60
worker.wrkr.socket_timeout=60
worker.wrkr.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=wrkr

Versions I'm using:

Using CATALINA_BASE:   /home/tomcat/www
Using CATALINA_HOME:   /home/tomcat/www
Using CATALINA_TMPDIR: /home/tomcat/www/temp
Using JRE_HOME:   /opt/jdk1.5
Server version: Apache Tomcat/5.5.27
Server built:   Aug 28 2008 10:08:26
Server number:  5.5.27.0
OS Name:Linux
OS Version: 2.6.18-5-686
Architecture:   i386
JVM Version:1.5.0_07-b03
JVM Vendor: Sun Microsystems Inc.

Server version: Apache/2.2.3
Server built:   Sep  6 2008 09:52:20

OS is debian etch, kernel is  2.6.18-5-686 GNU/Linux

Would be great if anyone could shed some light...

TIA

Gregor
-- 
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available
@ http://pgpkeys.pca.dfn.de:11371
@ http://pgp.mit.edu:11371/
skype:rc46fi

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

Re: Apache httpd vs Tomcat static content performance

2009-05-18 Thread Dillon Sellars

 Also, I'd be curious about the big disparity between the 16MiB files
 and the other 1MiB-32MiB files... It looks like all of them are
 relatively consistent at the KiB/sec rates you show - but suddenly
 there's a huge burst of speed on the 16MiB file (for httpd). So I'd
 be really curious to understand why the large disparity is evident
 there.

I believe Tomcat's default static memory cache size is 10MB, so you're going
to disk for each request at this point. This is configurable in the
Contexthttp://tomcat.apache.org/tomcat-6.0-doc/config/context.html
element.
I'm not too familiar with httpd's default memory cache, would be worthwhile
to try and make them match. httpd also has a fancier cache removal
algorithms (LRU and GDSF).
Also fun to take a look at the free chapter at
http://oreilly.com/catalog/9780596101060/chapter/ch04.pdf - a benchmark with
smaller files and concurrent users.  This benchmark has the # of worker
threads match the # of concurrent users. But I've seen benchmarks where NIO
/ APR beat out the JIO connector when using fewer threads than the # of
concurrent requests - APR / NIO have ways to freeing worker threads and
going asynchronous for static content (check out the bottom of Advanced IO
and Tomcat http://tomcat.apache.org/tomcat-6.0-doc/aio.html ).

Benchmarking is fun but always take it with a grain of salt.


On Mon, May 18, 2009 at 9:15 AM, David kerber dcker...@verizon.net wrote:

 Peter Crowther wrote:

 ...

 As a rough first cut, vmstat 5 and watch the numbers ;-).  iostat too, if
you can.  If CPU isn't pegged at 100% and the disk isn't at full capacity,
that's an interesting result as it implies the box has spare capacity and
there's contention elsewhere - often lock contention, as David Kerber has
recently seen!



 Indeed!  Getting rid of the extra locking took care of about 98% of the
issues, and changing to the Server jvm got me to over 99%.

 D



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

Re: AJP connections just stop working

2009-05-18 Thread kvancamp


My problem seems to be most similar to this post.  We are having intermittent
problems with the JBoss/Tomcat AJP 1.3 connector hanging.  From searching
the JBoss and Tomcat user forums, other issues that are similar to mine are:
http://marc.info/?l=tomcat-userm=116231271819840w=2
http://www.nabble.com/Problem-with-AJP-connector-td19657959.html#a19657959

neither of which really seems to offer a solution.  Here are my specifics:

We are running JBoss 4.2.2 (which uses Tomcat 6) running on Linux (RedHat
5.3) behind an IIS proxy, which is proxying to the JBoss AJP port.  I have
left AJP at its default settings in my server.xml:
  !-- A AJP 1.3 Connector on port 8009 --
  Connector protocol=AJP/1.3 port=8009
address=${jboss.bind.address}
 redirectPort=8443 /
The behavior I’m observing is only occurring about once every 2 weeks,
making it difficult to reproduce.  From the user’s perspective, the site is
unreachable.  The IIS proxy is logging this when the problem occurs:
[Tue Apr 21 04:13:14.775 2009] [3192:2500] [error] jk_ajp_common.c (1011):
(adastarNode) can't receive the response message from tomcat, network
problems or tomcat (172.17.3.240:8009) is down (errno=54)
[Tue Apr 21 04:13:14.775 2009] [3192:2500] [error] jk_ajp_common.c (1766):
(adastarNode) Tomcat is down or refused connection. No response has been
sent to the client (yet)
[Tue Apr 21 04:13:14.775 2009] [3192:2500] [info] jk_ajp_common.c (2186):
(adastarNode) sending request to tomcat failed (recoverable),  (attempt=1)

My JBoss instance is not logging any errors during this timeframe.  As far
as how to solve the problem, in one case the server was left like this for
several hours and seemed to recover on its own, only to hang again a couple
of hours later; otherwise the only solution that’s worked is to restart
JBoss.

The main difference I can observe in a thread dump is that the AJP acceptor
thread, which is normally in a RUNNABLE state, is in a WAITING state when
the hang occurs:
ajp-abeitmpr1.andesatpa.com%2F172.17.3.88-8009-Acceptor-0 daemon prio=10
tid=0x2aaad7a70400 nid=0x7dae in Object.wait()
[0x4424..0x44240c10]
   java.lang.Thread.State: WAITING (on object monitor)

Lately I’ve been trying to also use netstat to look at the problem when a
hang occurs, but I’m not sure I’ve caught it during a true hang.  It appears
to me that I have a growing number of ESTABLISHED connections prior to the
hang, plus one CLOSE_WAIT connection:
[it...@abeitmpr1 log]$ netstat -vatn |grep 8009
tcp0  0 172.17.3.88:80090.0.0.0:*  
LISTEN
tcp  516  0 172.17.3.88:8009172.17.5.42:2154   
ESTABLISHED
tcp0  0 172.17.3.88:8009172.17.5.42:3690   
ESTABLISHED
tcp  514  0 172.17.3.88:8009172.17.5.42:2159   
ESTABLISHED
tcp  514  0 172.17.3.88:8009172.17.5.42:2158   
ESTABLISHED
tcp  514  0 172.17.3.88:8009172.17.5.42:2144   
ESTABLISHED
tcp0  0 172.17.3.88:8009172.17.5.42:3680   
ESTABLISHED
tcp  514  0 172.17.3.88:8009172.17.5.42:2171   
ESTABLISHED
tcp  514  0 172.17.3.88:8009172.17.5.42:2170   
ESTABLISHED
tcp0  0 172.17.3.88:8009172.17.5.42:1395   
ESTABLISHED
tcp0  0 172.17.3.88:8009172.17.5.42:2935   
ESTABLISHED
tcp0  0 172.17.3.88:8009172.17.5.42:4724   
ESTABLISHED
tcp  514  0 172.17.3.88:8009172.17.5.42:2120   
ESTABLISHED
tcp0  0 172.17.3.88:8009172.17.5.42:2375   
ESTABLISHED
tcp  516  0 172.17.3.88:8009172.17.5.42:2119   
ESTABLISHED
tcp  514  0 172.17.3.88:8009172.17.5.42:2118   
ESTABLISHED
tcp  514  0 172.17.3.88:8009172.17.5.42:2372   
ESTABLISHED
tcp0  0 172.17.3.88:8009172.17.5.42:1114   
ESTABLISHED
tcp  514  0 172.17.3.88:8009172.17.5.42:2143   
ESTABLISHED
tcp0  0 172.17.3.88:8009172.17.5.42:1116   
ESTABLISHED
tcp  514  0 172.17.3.88:8009172.17.5.42:2131   
ESTABLISHED
tcp0  0 172.17.3.88:8009172.17.5.42:3923   
ESTABLISHED
tcp0  0 172.17.3.88:8009172.17.5.42:2133   
ESTABLISHED
tcp  514  0 172.17.3.88:8009172.17.5.42:2132   
ESTABLISHED
tcp  514  0 172.17.3.88:8009172.17.5.42:2347   
ESTABLISHED
tcp0  0 172.17.3.88:8009172.17.5.42:1834   
ESTABLISHED
tcp  514  0 172.17.3.88:8009172.17.5.42:2093   
ESTABLISHED
tcp0  0 172.17.3.88:8009172.17.5.42:1837   
ESTABLISHED
tcp

RE: Tomcat not closing threads


need to know if Apache MPM prefork or Apache worker is configured
$APACHE_HOME/bin/Apache -l

*any compiled-in modules with 'mpm' in the module-name is prefork*
*any compiled-in modules with 'worker' in the module-name is worker*

Martin Gainty 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




 Date: Mon, 18 May 2009 08:45:43 -0700
 From: chetan_chh...@yahoo.com
 Subject: Re: Tomcat not closing threads
 To: users@tomcat.apache.org
 
 So what you are suggesting is my mod_jk and tomcat parameters in server.xml 
 are messed up .. 
 
 Here is my current setup I have one apache load balancing to 2 tomcat workers
 Maxclients = 512 
 ThreadsPerChild = 256
 Connection_pool_size = 256 
 Tomcat MaxThreads = 150 
 
 I will suggest my team to change this to ... 
 connection_pool_size = 120  - which means that I will have 120*2(2 apache 
 server procs) = 240 threads per tomcat 
 Tomcat maxthreads = 300
 
 So out of total 512 worker threads , a max of 480 threads will be used by 
 mod_jk leaving the rest for serving static content. 
 
 is my math correct? 
 
 Thanks!
 
 
 
 
 From: Martin Gainty mgai...@hotmail.com
 To: Tomcat Users List users@tomcat.apache.org
 Sent: Monday, May 18, 2009 11:23:58 AM
 Subject: RE: Tomcat not closing threads
 
 
 some documentation:
 
 http://httpd.apache.org/docs/2.0/mod/mpm_common.html
 MaxClients:
 The MaxClients directive sets the limit on the number of simultaneous 
 requests that will be served. 
 Any connection attempts over the MaxClients limit will normally be queued, up 
 to a number based on the ListenBacklog directive. 
 Once a child process is freed at the end of a different request, the 
 connection will then be serviced.
 For non-threaded servers (i.e., prefork), MaxClients translates into the 
 maximum number of child processes that will be launched to serve requests. 
 The default value is 256; to increase it, you must also raise ServerLimit.
 For threaded and hybrid servers (e.g. beos or worker) MaxClients restricts 
 the total number of threads that will be available to serve clients. 
 The default value for beos is 50. 
 For hybrid MPMs (your situation) the default value is 16 (ServerLimit) 
 multiplied by the value of ThreadsPerChild. 
 Therefore, to increase MaxClients to a value that requires more than 16 
 processes, you must also raise ServerLimit.
 
 ThreadsPerChild
 This directive sets the number of threads created by each child process.
 The child creates these threads at startup and never creates more. 
 If using an MPM like mpm_winnt, where there is only one child process, this 
 number should be high enough to handle the entire load of the server. 
 If using an MPM like worker, where there are multiple child processes, the 
 total number of threads should be high enough to handle the common load on 
 the server.
 The default value for ThreadsPerChild is 64 when used with mpm_winnt 
 The default value is 25 when used with other configurations such as worker
 
 also from mladens discussion of connection_pool_size calcs based on Apache 
 HTTPD Prefork vs Worker 
 http://www.mail-archive.com/users@tomcat.apache.org/msg14767.html
 Apache Prefork configuration
 Apache 1.3 and Apache 2.x-prefork create a separate child process for
 each client connection, meaning that if you have default
 250 MaxClients, you can end up with MaxClients * connection_pool_size
 connections to the Tomcat, that would in your case be 25.
 (and in the case of ThreadsPerChild parameter 
 MaxClients*64*connection_pool_size)
 
 Apache Worker configuration
 With worker mpm the connection_pool_size defaults to ThreadsPerChild,
 that in the final gives the MaxClients connections to the Tomcat.
 So the default value for connection_pool_size is always ThreadsPerChild
 that with prefork mpm is by design always 1.
 (in the case of ThreadsPerChild parameter not being null 
 MaxClients*ThreadsPerChild)
 
 HTH
 Martin 
 __ 
 Verzicht und

Re: Tomcat not closing threads

Apache is using worker mpm 
Server version: Apache/2.0.59  HP-UX_Apache-based_Web_Server
Server built:   Aug 21 2007 13:59:06
Server's Module Magic Number: 20020903:12
Server loaded:  APR 0.9.12, APR-UTIL 0.9.12
Compiled using: APR 0.9.12, APR-UTIL 0.9.12
Architecture:   64-bit
Server compiled with
 -D APACHE_MPM_DIR=server/mpm/worker





From: Martin Gainty mgai...@hotmail.com
To: Tomcat Users List users@tomcat.apache.org
Sent: Monday, May 18, 2009 2:44:45 PM
Subject: RE: Tomcat not closing threads


need to know if Apache MPM prefork or Apache worker is configured
$APACHE_HOME/bin/Apache -l

*any compiled-in modules with 'mpm' in the module-name is prefork*
*any compiled-in modules with 'worker' in the module-name is worker*

Martin Gainty 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




 Date: Mon, 18 May 2009 08:45:43 -0700
 From: chetan_chh...@yahoo.com
 Subject: Re: Tomcat not closing threads
 To: users@tomcat.apache.org
 
 So what you are suggesting is my mod_jk and tomcat parameters in server.xml 
 are messed up .. 
 
 Here is my current setup I have one apache load balancing to 2 tomcat workers
 Maxclients = 512 
 ThreadsPerChild = 256
 Connection_pool_size = 256 
 Tomcat MaxThreads = 150 
 
 I will suggest my team to change this to ... 
 connection_pool_size = 120  - which means that I will have 120*2(2 apache 
 server procs) = 240 threads per tomcat 
 Tomcat maxthreads = 300
 
 So out of total 512 worker threads , a max of 480 threads will be used by 
 mod_jk leaving the rest for serving static content. 
 
 is my math correct? 
 
 Thanks!
 
 
 
 
 From: Martin Gainty mgai...@hotmail.com
 To: Tomcat Users List users@tomcat.apache.org
 Sent: Monday, May 18, 2009 11:23:58 AM
 Subject: RE: Tomcat not closing threads
 
 
 some documentation:
 
 http://httpd.apache.org/docs/2.0/mod/mpm_common.html
 MaxClients:
 The MaxClients directive sets the limit on the number of simultaneous 
 requests that will be served. 
 Any connection attempts over the MaxClients limit will normally be queued, up 
 to a number based on the ListenBacklog directive. 
 Once a child process is freed at the end of a different request, the 
 connection will then be serviced.
 For non-threaded servers (i.e., prefork), MaxClients translates into the 
 maximum number of child processes that will be launched to serve requests. 
 The default value is 256; to increase it, you must also raise ServerLimit.
 For threaded and hybrid servers (e.g. beos or worker) MaxClients restricts 
 the total number of threads that will be available to serve clients. 
 The default value for beos is 50. 
 For hybrid MPMs (your situation) the default value is 16 (ServerLimit) 
 multiplied by the value of ThreadsPerChild. 
 Therefore, to increase MaxClients to a value that requires more than 16 
 processes, you must also raise ServerLimit.
 
 ThreadsPerChild
 This directive sets the number of threads created by each child process.
 The child creates these threads at startup and never creates more. 
 If using an MPM like mpm_winnt, where there is only one child process, this 
 number should be high enough to handle the entire load of the server. 
 If using an MPM like worker, where there are multiple child processes, the 
 total number of threads should be high enough to handle the common load on 
 the server.
 The default value for ThreadsPerChild is 64 when used with mpm_winnt 
 The default value is 25 when used with other configurations such as worker
 
 also from mladens discussion of connection_pool_size calcs based on Apache 
 HTTPD Prefork vs Worker 
 http://www.mail-archive.com/users@tomcat.apache.org/msg14767.html
 Apache Prefork configuration
 Apache 1.3 and Apache 2.x-prefork create a separate child process for
 each client connection, meaning that if you have default
 250 MaxClients, you can end up with MaxClients * connection_pool_size
 connections to the Tomcat, that would in your case be 25.

Re: Tomcat, Realm, and context.xml

2009-05-18 Thread Mark Thomas

Greg Allen wrote:
 I am trying to use ApacheDS 1.5 with Tomcat 5.5.17.

Try a later version. You may be hitting multiple bugs that have since
been fixed.

 Now this really confuses me.  Why is it using JAASRealm?  That's not
 configured

The JAAS Realm is the default Realm Tomcat falls back to if no other
Realm can be found. I would guess your config is wrong.

Mark



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

RE: MAX Simultaneous connections with Tomcat on Windows XP Pro

2009-05-18 Thread Arijit Sarkar Job Gmail

This link on Microsoft specifies this very issue..
http://support.microsoft.com/kb/314882
 It also says 
 The connection limit refers to the number of redirector-based connections and 
is enforced for any file, print, named pipe, or mail slot session. The TCP 
connection limit is not enforced, but it may be bound by legal agreement to not 
permit more than 10 clients.  

Doesn’t this solidify our point that the connection limit is not for Http 
connections?

If used with IIS (a Microsoft product), it might be possible that they are 
enforcing this limit on IIS too. But with Tomcat we should be ok.. What say ?

-Original Message-
From: David kerber [mailto:dcker...@verizon.net] 
Sent: Monday, May 18, 2009 12:40 PM
To: Tomcat Users List
Subject: Re: MAX Simultaneous connections with Tomcat on Windows XP Pro

Christopher Schultz wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Peter,

 On 5/18/2009 3:19 AM, Peter Crowther wrote:
   
 From: Arijit Sarkar Job Gmail [mailto:arijit.k.sar...@gmail.com] So
 If I have an web application deployed on tomcat and windows XP
 pro, theoretically, unlimited users can connect to the application 
 simultaneously? Tomcat or Windows XP does not place any limits to
 that?
   
 There are no limits imposed by XP's license - XP's 10-connection
 limit applies only to it acting as a SMB server, and doesn't affect
 anything else.
 

 I have seen claims that it also affects IIS connections. Is it just that
 anything server-related that Microsoft sells is limited to 10 (total?
 per package?) connections when running on a non-server-branded version
 of Windows?
   
Yes.  We have run into that issue ourselves.  It's handled the same as 
if a server had been trying to handle more connections than it was 
licensed for.  This definitely includes IIS clients and SMB shares.  I 
don't know if it also includes microsoft ftp and e-mail connections, but 
it may (probably does, in fact).

D



-
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: running tomcat5 -- as a service under 64-bit windows?

2009-05-18 Thread Mark Thomas

w...@serensoft.com wrote:
 Plus, the mofidied/64-bit-savvy tomcat5w.exe which is supposed to set
 parameters for the service, complains that 'tomcat5' doesn't exist.

When you install the service you have to name it tomcat5. It is a
'feature' of that service wrapper that for a service XXX the binarie
smust be named XXX.exe and XXXw.exe

Mark


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

Re: Trouble building tcnative

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rainer,

On 5/18/2009 1:11 PM, Rainer Jung wrote:
 you'll find a download of 1.1.16, which builds exactly like the 1.1.12
 you were already trying to use (configure et.al.).

Yup, I already did this: no problems with the 1.1.16 version (the README
file was also fixed :).

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

iEYEARECAAYFAkoRtHcACgkQ9CaO5/Lv0PBRpACghHJgwin6K/8MZ/UDaTUE0xT1
tK0AoJXtSS5n745Y8S9PcBWsPDgfHYke
=q0Cf
-END PGP SIGNATURE-

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

Re: Trouble building tcnative

On 18.05.2009 19:38, Martin Gainty wrote:
 dl/l tomcat-native-1.1.16-win32-src from
 http://tomcat.apache.org/download-native.cgi
 Cannot open include file: 'apr.h': No such file or directory?
 also i did'nt see makefile ?

Assuming yoiu're asking about Windows build? It's not yet documented,
but there are the necessary .dsp/.dsw files. You'll need MS toolset.
Don't know, whether cygwin or similar will work.

With MS tools, you'll use the .dsp/.dsw files instead of Makefile. On
*nix like OS, the Makefile is generated by configure.

apr.h: On all platforms you'll need apr to build tcnative. On Windows
with MS tools it is assumes, that the apr source gets unpacked besides
jni/native (as jni/apr).

Regards,

Rainer
 
 
 Date: Mon, 18 May 2009 19:11:10 +0200
 From: rainer.j...@kippdata.de
 To: users@tomcat.apache.org
 Subject: Re: Trouble building tcnative

 On 18.05.2009 18:03, Juha Laiho wrote:
 Christopher Schultz wrote:
 I've never built tcnative before, but I'm no stranger to the standard
 UNIX source package build process. I'm having a bit of difficulty
 building this.
 ...

 ...and this is where things fall apart for me. Here's the output of
 configure (apologies for any bad line wrapping):

 $ ./configure --with-apr=/usr/bin/apr-1-config
 checking build system type... i686-pc-linux-gnu
 ...
 ./configure: line 4315: APR_BUILD_DIR: command not found
 ./configure: line 4316: APR_INCLUDES: command not found
 ...

 This is followed by hundreds of lines of line xyz: [whatever]: command
 not found.
 That might be an issue with either the shell you're using to start
 configure, or the default shell for your account. But then, this
 is just a quick guess. You might want (or not want, actually, but..)
 to look at perhaps the ten or so lines before 4315 in the configure
 script. It may also be that the script itself is somehow broken.
 There was a bug in tcnative 1.1.12 with this symptom:

 IFS problem in native/build/tcnative.m4 (rjung) 

 It's likely you hit it. I suggest using the latest tcnative version,
 because there were also a couple of functional bugs fixed. On

 http://tomcat.apache.org/download-native.cgi

 you'll find a download of 1.1.16, which builds exactly like the 1.1.12
 you were already trying to use (configure et.al.).

 Regards,

 Rainer

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

Re: running tomcat5 -- as a service under 64-bit windows? SOLVED

2009-05-18 Thread will trillich

Figured it out!


How to run TOMCAT 5 as a SERVICE when running under WINDOWS 64-bit
(enterprise 2003 in our case, but presumably this would apply to other
64-bit windows implementations):

Tomcat v5 is 32-bit, which won't run as a service under Java 64-bit.

The advice at
http://www.nabble.com/running-tomcat-5.5-as-a-service-on-64bit-windows-td6821449.html
takes us to
http://svn.apache.org/viewvc/tomcat/connectors/trunk/procrun/bin/amd64/

where we download the 64-bit wrappers (tomcat5.exe and tomcat5w.exe)
to replace the originals (in \tomcat\bin).

Then at the command line:
cd \tomcat\bin
service.bat install whatever
tomcat5w.exe //ES//whatever

Set options, and voila! Start menu - admin tools - services shows
apache tomcat whatever and you can start it and stop it from there.

=

Now we've got a new, follow-up question -- in a separate email.


On Mon, May 18, 2009 at 2:12 PM, Mark Thomas ma...@apache.org wrote:
 w...@serensoft.com wrote:
 Plus, the mofidied/64-bit-savvy tomcat5w.exe which is supposed to set
 parameters for the service, complains that 'tomcat5' doesn't exist.

 When you install the service you have to name it tomcat5. It is a
 'feature' of that service wrapper that for a service XXX the binarie
 smust be named XXX.exe and XXXw.exe


-- 
will trillich
Our only real economic security lies in our power to meet human
needs. -- S.Covey, the 8th Habit

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

Re: maxwait in dbconnetion is not workiing for first time.

2009-05-18 Thread S Arvind

Martin , i think its not session, since i tried same thing in wget, first
time with network connection is working fine.
but without network connection , status is keep on waiting for response. I
think linux wget will have session management or any i think. will be any
other probs.. i cant use session.invalidate , since if the page is called
from main application then the current all session attributes will be blown
away...

Arvind S

*
Many of lifes failure are people who did not realize how close they were to
success when they gave up.
-Thomas Edison*

On Mon, May 18, 2009 at 7:05 PM, Martin Gainty mgai...@hotmail.com wrote:

means your session to TC is still live
suggest attenuate connectionTimeout in connector config in server.xml

in code you can always session.invalidate()

http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html#invalidate()http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html#invalidate%28%29

Martin Gainty
I have not failed. I've just found 10,000 ways that won't work - edison
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
dient lediglich dem Austausch von Informationen und entfaltet keine
rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire
informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie
de ceci est interdite. Ce message sert à l'information seulement et n'aura
pas n'importe quel effet légalement obligatoire. Étant donné que les email
peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
aucune responsabilité pour le contenu fourni.

From: arvindw...@gmail.com
Date: Mon, 18 May 2009 16:55:30 +0530
Subject: maxwait in dbconnetion is not workiing for first time.
To: users@tomcat.apache.org

So first i established the connection first from the jsp page, it gets
done.
After that i plugged-out my network cable and tried to make connection by
that same jsp file, but i didnt get exception , it keep on running. but
if i
refreshed the page again after few mins the exception is coming. but why
not
in first request itself. I need it in first request itself for my
failover
model. my maxwait is 1000ms

Resource auth=Container description=Database DSN name=jdbc/dbname
scope=Shareable type=javax.sql.DataSource url=jdbc:postgresql://
1.1.1.180/dbname driverClassName=org.postgresql.Driver
username=
password=y maxActive=10 maxIdle=1 minIdle=0
removeAbandoned=true removeAbandonedTimeout=60 logAbandoned=true
maxWait=1000 /

Is it bug or my mistake ?

-Arvind S

*
Many of lifes failure are people who did not realize how close they were
to
success when they gave up.
-Thomas Edison*

_
Hotmail® goes with you.

http://windowslive.com/Tutorial/Hotmail/Mobile?ocid=TXT_TAGLM_WL_HM_Tutorial_Mobile1_052009

Re: Apache httpd vs Tomcat static content performance [Revised/Updated]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

After reading some of your feedback, I've decided to make some changes:

- - Using TC 6.0.18 exclusively instead of 5.5
- - Using tcnative 1.1.16 instead of 1.1.12
- - Using httpd 2.2.11 instead of 2.2.10
- - Running tests for a certain amount of time instead of a
  certain number of requests

I have some preliminary results. Just as a smoke-test, I ran my tests
for 10 seconds each (10 seconds per file size, per server config) which
means that I can get a complete set of results in 15 minutes. The
results are borderline useless, but you can already start to see the
different configurations differentiate themselves:

File Size   Apache httpdCoyote  Coyote APR  Coyote APR -sendfile
Coyote
NIO Coyote NIO –sendfile
4KiB4984.02 3833.73 5674.66 5433.23 3128.34 3247.66
8KiB8795.03 7468.45 9465.31 10015.065616.81 5674.44
16KiB   15913.3812901.2116437.4016426.36
10316.2710171.56
32KiB   27525.0721270.0725361.0925557.25
17482.0917803.41
64KiB   47500.6132990.8138590.0237454.34
31113.9327034.23
128KiB  63920.7242161.1758548.6446011.547167.93 
31891.99
256KiB  80030.0251749.2182274.4754119.36256.29  
34057.95
512KiB  95386.2745987.1589375.5249531.11512.10  
30722.53
1MiB105059.69   50127.8489988.7950886.451020.18 
31309.67
2MiB99790.5651408.4195647.3844390.742032.38 
32697.59
4MiB100633.551138.52105273.11   54729.794424.93 
34088.29
8MiB99595.0351523.9298445.8356116.617936.50 
32557.95
16MiB   99126.6551440.4598111.8255406.30
15400.8232681.28
32MiB   99018.9452719.7496605.4854410.23
28989.7533275.04

Quick setup: single localhost client (no concurrency), no keepalives, 10
second max samples per file size per server config.

I re-ran the NIO+sendfile tests afterward since the server was busy
(recompiling gcc as well as serving HTTP requests to whomever happens to
be using it right now) and I figured it was a fluke. The second test
showed the same results: NIO looks great until it hits the 128KiB file,
when it experiences a dramatic drop-off in performance. I'll have to
look into that: the NIO connector /without/ sendfile enabled does not
appear to suffer the same drop-off in performance (though it appears to
be the weakest contender in the bunch).

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

iEYEARECAAYFAkoRt2gACgkQ9CaO5/Lv0PCqZgCeN6zXJFY0E5kquz5//CsnaFGN
ZIwAn3b++7waMKoi9iJ2X0pyocKK7d/5
=UWiA
-END PGP SIGNATURE-

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

Re: Running out of tomcat threads - why many threads in RUNNABLE stage even with no activity

On 13.05.2009 23:28, Pantvaidya, Vishwajit wrote:
 My setup is tomcat 5.5.17 + mod_jk 1.2.15 + httpd 2.2.2. I am using 
 AJP1.3. Every 2-3 days with no major load, tomcat throws the error: 
 SEVERE: All threads (200) are currently busy, waiting...
 
 I have been monitoring my tomcat TP-Processor thread behavior over 
 extended time intervals and observe that: - even when there is no 
 activity on the server, several TP-Processor threads are in RUNNABLE 
 state while few are in WAITING state - RUNNABLE threads stack trace 
 shows java.lang.Thread.State: RUNNABLE at 
 java.net.SocketInputStream.socketRead0(Native Method)...

We would need to see more of the stack. It's likely that those are
connected to the web server, waiting for the next request.

 - WAITING thread stack trace shows java.lang.Thread.State: WAITING 
 on 
 org.apache.tomcat.util.threads.threadpool$controlrunna...@53533c55

Likely idle in the pool, availale to handle new connections.

 - tomcat adds 4 new TP-Processor threads when a request comes in and 
 it can find no WAITING threads
 
 So I conclude that my tomcat is running out of threads due to many 
 threads being in RUNNABLE state when actually they should be in 
 WAITING state. Is that happening because of the socket_keepalive in 
 my workers.properties shown below? Why are threads added in bunches 
 of 4 - is there any way to configure this?

Those socketRead0 threads (Disclaimer: I already said we need more of
the stack to be sure) are connected to the web server, waiting for new
requests. As long as the new requests come from one of theose web server
processes, no new thread is needed to handle them.

socket_keepalive is not directly related to that. It tries to workaround
a problem, where some component (e.g. firewall) between web server and
Tomcat cuts an idle connection without letting the web server and Tomcat
know.

If you want to free the thread handling the persistent connections, you
caqn use the connection pool timeout on the jk side and also the
connection pool minimum size (e.g. setting it to 0).

On the Tomcat side use connetionTimeout. Be warned, that jk and Tomcat
do not use the same time unit for those parameters. Have a look at the
timeouts documentation of mod_jk.

 My workers config is:
 
 Worker...type=ajp13 Worker...cachesize=10 Worker...cache_timeout=600
  Worker...socket_keepalive=1 Worker...recycle_timeout=300
 
 Earlier posts related to this issue on the list seem to recommend 
 tweaking: - several timeouts - JkOptions +DisableReuse

Very last resort. Should not be needed and might obscure some other problem.

 I am planning to do the following to resolve our problem: - upgrade 
 jk to latest version - e.g. 1.2.28 - replace recycle_timeout with 
 connection_pool_timeout - add connectionTimeout in server.xml - add 
 JkOptions +DisableReuse
 
 Please let me know if this is okay or suggestions if any.

I suspect, that during the time of the all threads are currently busy
message, something in or behind your app was slow and so requests got
stuck in front of Tomcat, the web server pool was growing until it
connected 200 web server processes/threads trying to send requests to
Tomcat. To find out what the root cause was, you'll need to make the
thread dumps during the problem time.

Also note, that the maximum concurrency in your web server layer should
be a good fit to the maximum concurrency (thread pool size) in the
Tomcat layer.

Regards,

Rainer

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

Re: Running out of tomcat threads - why many threads in RUNNABLE stage even with no activity

On 14.05.2009 20:29, Pantvaidya, Vishwajit wrote:
 I set connectionTimeout in server.xml to 60 and now the RUNNABLE
 threads go back to WAITING stage after that time.
 
 But our other servers which are running the same configuration, same
 webapp and do not have connectionTimeout set in server.xml, do not
 show so many RUNNABLE threads, but more WAITING threads. So looks
 like the threads are getting recycled properly there.
 
 Any idea why could this be? Could it be the OS (all servers run Linux
 but I do not know which flavors/versions)?

Different web server configuration? Different load specifics?

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

never mind :)

2009-05-18 Thread w...@serensoft.com

We just got Tomcat 5 to work as a service on windows 64-bit, woo hoo!
(see email with subject running tomcat5 -- as a service under 64-bit
windows? SOLVED.)

We thought we had another new snag, but there's just a firewall or
network issue.

We now return you to your regularly scheduled email. :)

-- 
will trillich
Our only real economic security lies in our power to meet human
needs. -- S.Covey, the 8th Habit

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

Re: Problems configuring mod_jk

Hi Gregor,

On 18.05.2009 20:07, Gregor Schneider wrote:
 Hi guys,
 
 I'm about to update an old Tomcat-instance (5.5.quite_old) to the
 latest 5.5, also I'm about to update an outdated mod_jk to the latest
 version.
 
 The old config of mod_jk had quite some depricated directions
 included, so I changed them (opefully) according to the doc I found
 here:http://tomcat.apache.org/connectors-doc/reference/workers.html
 
 However, when I check the logs from mod_jk, I always get the following
 error-messages (multiple times, I guess it's one for every virtual
 host in Apache HTTPD):
 
 [2009-05-18 19:34:44][18754:3078399680] [error]
 uri_worker_map_ext::jk_uri_worker_map.c (506): Could not find worker
 with name 'worker' in uri map post proces
 sing.
 
 However, I do not see where I defined a worker with the name worker.

The error means: you told mod_jk to use it, but you forgot to define it.

 All vhost-definitions within Apache are alike when it comes to the
 jk-specs, thus I'm just posting a sample vhost-definition:
 
 VirtualHost *:443
 [ ...]

Lots of mounts telling jk to use a worker named worker (the last token
in the line)

 JkMount /SingleSignOnCLUE/* worker
 JkMount /LoginData/* worker
 JkMount /j_security_check worker
 JkMount /IndexCLUE/* worker
 JkMount /BMIWizardCLUE/* worker
 JkMount /RRWizardCLUE/* worker
 JkMount /DiabetesCLUE/* worker
 JkMount /HyperlipCLUE/* worker
 JkMount /ForeignTravelCLUE/* worker
 JkMount /MartialArtsCLUE/* worker
 #
 JkRequestLogFormat %b %m %q %s %T
 
 [ ...]
 /VirtualHost
 
 My jk.conf:
 
 JkWorkersFile /etc/apache2/workers.properties
 JkLogFile |/usr/bin/cronolog -S/var/log/apache2/mod_jk.log
 /var/log/apache2/%Y/%m/mod_jk-%d.log
 JkLogLevel info
 JkLogStampFormat [%F %T]
 
 
 And here come my workers.properties:

No worker worker here, only worker wrkr. Either use wrkr in
JkMount or worker.worker here.

 # workers.properties - ajp13
 #
 # List workers
 worker.list=wrkr
 # Define wrkr
 worker.wrkr.port=8009
 worker.wrkr.host=127.0.0.1
 worker.wrkr.type=ajp13
 worker.wrkr.connection_pool_size=30

Don't use the pool size for Apache. We choose it automatically.

 worker.wrkr.connection_pool_timeout=60
 worker.wrkr.socket_timeout=60

That's more or less the only of the timeouts I don't really like. Oh
well ...
Look at the timeouts docs page, especially the cping/cpong is useful.

 worker.wrkr.lbfactor=1
 worker.loadbalancer.type=lb
 worker.loadbalancer.balance_workers=wrkr
 
 Versions I'm using:
 
 Using CATALINA_BASE:   /home/tomcat/www
 Using CATALINA_HOME:   /home/tomcat/www
 Using CATALINA_TMPDIR: /home/tomcat/www/temp
 Using JRE_HOME:   /opt/jdk1.5
 Server version: Apache Tomcat/5.5.27
 Server built:   Aug 28 2008 10:08:26
 Server number:  5.5.27.0
 OS Name:Linux
 OS Version: 2.6.18-5-686
 Architecture:   i386
 JVM Version:1.5.0_07-b03
 JVM Vendor: Sun Microsystems Inc.
 
 Server version: Apache/2.2.3
 Server built:   Sep  6 2008 09:52:20
 
 OS is debian etch, kernel is  2.6.18-5-686 GNU/Linux
 
 Would be great if anyone could shed some light...
 
 TIA
 
 Gregor

Regards,

Rainer

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

Re: AJP connections just stop working

On 18.05.2009 20:33, kvancamp wrote:
 My problem seems to be most similar to this post.  We are having intermittent
 problems with the JBoss/Tomcat AJP 1.3 connector hanging.  From searching
 the JBoss and Tomcat user forums, other issues that are similar to mine are:
 http://marc.info/?l=tomcat-userm=116231271819840w=2
 http://www.nabble.com/Problem-with-AJP-connector-td19657959.html#a19657959
 
 neither of which really seems to offer a solution.  Here are my specifics:
 
 We are running JBoss 4.2.2 (which uses Tomcat 6) running on Linux (RedHat
 5.3) behind an IIS proxy, which is proxying to the JBoss AJP port.  I have
 left AJP at its default settings in my server.xml:
   !-- A AJP 1.3 Connector on port 8009 --
   Connector protocol=AJP/1.3 port=8009
 address=${jboss.bind.address}
  redirectPort=8443 /
 The behavior I’m observing is only occurring about once every 2 weeks,
 making it difficult to reproduce.  From the user’s perspective, the site is
 unreachable.  The IIS proxy is logging this when the problem occurs:
 [Tue Apr 21 04:13:14.775 2009] [3192:2500] [error] jk_ajp_common.c (1011):
 (adastarNode) can't receive the response message from tomcat, network
 problems or tomcat (172.17.3.240:8009) is down (errno=54)
 [Tue Apr 21 04:13:14.775 2009] [3192:2500] [error] jk_ajp_common.c (1766):
 (adastarNode) Tomcat is down or refused connection. No response has been
 sent to the client (yet)
 [Tue Apr 21 04:13:14.775 2009] [3192:2500] [info] jk_ajp_common.c (2186):
 (adastarNode) sending request to tomcat failed (recoverable),  (attempt=1)
 
 My JBoss instance is not logging any errors during this timeframe.  As far
 as how to solve the problem, in one case the server was left like this for
 several hours and seemed to recover on its own, only to hang again a couple
 of hours later; otherwise the only solution that’s worked is to restart
 JBoss.
 
 The main difference I can observe in a thread dump is that the AJP acceptor
 thread, which is normally in a RUNNABLE state, is in a WAITING state when
 the hang occurs:
 ajp-abeitmpr1.andesatpa.com%2F172.17.3.88-8009-Acceptor-0 daemon prio=10
 tid=0x2aaad7a70400 nid=0x7dae in Object.wait()
 [0x4424..0x44240c10]
java.lang.Thread.State: WAITING (on object monitor)
 
 Lately I’ve been trying to also use netstat to look at the problem when a
 hang occurs, but I’m not sure I’ve caught it during a true hang.  It appears
 to me that I have a growing number of ESTABLISHED connections prior to the
 hang, plus one CLOSE_WAIT connection:
 [it...@abeitmpr1 log]$ netstat -vatn |grep 8009
 tcp0  0 172.17.3.88:80090.0.0.0:*  
 LISTEN
 tcp  516  0 172.17.3.88:8009172.17.5.42:2154   
 ESTABLISHED
 tcp0  0 172.17.3.88:8009172.17.5.42:3690   
 ESTABLISHED
 tcp  514  0 172.17.3.88:8009172.17.5.42:2159   
 ESTABLISHED
 tcp  514  0 172.17.3.88:8009172.17.5.42:2158   
 ESTABLISHED
 tcp  514  0 172.17.3.88:8009172.17.5.42:2144   
 ESTABLISHED
 tcp0  0 172.17.3.88:8009172.17.5.42:3680   
 ESTABLISHED
 tcp  514  0 172.17.3.88:8009172.17.5.42:2171   
 ESTABLISHED
 tcp  514  0 172.17.3.88:8009172.17.5.42:2170   
 ESTABLISHED
 tcp0  0 172.17.3.88:8009172.17.5.42:1395   
 ESTABLISHED
 tcp0  0 172.17.3.88:8009172.17.5.42:2935   
 ESTABLISHED
 tcp0  0 172.17.3.88:8009172.17.5.42:4724   
 ESTABLISHED
 tcp  514  0 172.17.3.88:8009172.17.5.42:2120   
 ESTABLISHED
 tcp0  0 172.17.3.88:8009172.17.5.42:2375   
 ESTABLISHED
 tcp  516  0 172.17.3.88:8009172.17.5.42:2119   
 ESTABLISHED
 tcp  514  0 172.17.3.88:8009172.17.5.42:2118   
 ESTABLISHED
 tcp  514  0 172.17.3.88:8009172.17.5.42:2372   
 ESTABLISHED
 tcp0  0 172.17.3.88:8009172.17.5.42:1114   
 ESTABLISHED
 tcp  514  0 172.17.3.88:8009172.17.5.42:2143   
 ESTABLISHED
 tcp0  0 172.17.3.88:8009172.17.5.42:1116   
 ESTABLISHED
 tcp  514  0 172.17.3.88:8009172.17.5.42:2131   
 ESTABLISHED
 tcp0  0 172.17.3.88:8009172.17.5.42:3923   
 ESTABLISHED
 tcp0  0 172.17.3.88:8009172.17.5.42:2133   
 ESTABLISHED
 tcp  514  0 172.17.3.88:8009172.17.5.42:2132   
 ESTABLISHED
 tcp  514  0 172.17.3.88:8009172.17.5.42:2347   
 ESTABLISHED
 tcp0  0 172.17.3.88:8009172.17.5.42:1834   
 ESTABLISHED
 tcp  514  0 172.17.3.88:8009

Re: Running out of tomcat threads - why many threads in RUNNABLE stage even with no activity

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Vishwajit,

On 5/18/2009 2:01 PM, Pantvaidya, Vishwajit wrote:
 Yes, sure - we will upgrade at some point of
 time. But since upgrading all our servers will be some work, that may
 not happen right away.

Upgrading mod_jk is the least painful of all of these, and the most
likely to affect you.

 Here are figures from 3 of the servers which
 have not yet run out of threads (so the thread count does not add up
 to 200). I have taken these late at night when no users are present,
 so I was expecting all threads to be Waiting for tomcat thread-pool.
 
 1. Total TP-Processor threads 48, Waiting 46, Runnable 2
 2. Total TP-Processor threads 40, Waiting 29, Runnable 11
 3. Total TP-Processor threads 120, Waiting 7, Runnable 113

Are you sure you aren't seeing any traffic, even that late at night?
What if you watch the access logs? Are there requests actively being
serviced?

 Do you think this could be because of the
 application? I was under the impression that there is some tomcat
 config parameter that controls this - which was set to 4.

No, Tomcat uses precisely 1 thread to handle each incoming HTTP request.
If keepalives are used, multiple requests may be handled by the same
thread before it is returned to the pool, or different threads may be
used to serve different requests from the single connection, but in
either case, no more than 1 thread will be used to service a single HTTP
request.

 My workers config is:
 
 Worker...type=ajp13
 Worker...cachesize=10
 Are you using the prefork MPM? If so, cachesize should be /1/.
 
 [Pantvaidya, Vishwajit] Could you please elaborate. What is the
 prefork MPM?

The MPM is the concurrency strategy employed by Apache httpd. Either you
are using the prefork MPM which starts multiple httpd processes to
handle requests, or you are using the worker MPM which starts multiple
threads to handle requests. Actually, mod_jk should be able to
auto-detect the appropriate cachesize (called connection_pool_size,
now), so you shouldn't have to set this.

 Worker...cache_timeout=600 Worker...socket_keepalive=1 
 Worker...recycle_timeout=300
 Are these timeouts necessary? Why not simply let the connections
 stay alive all the time?
 
 [Pantvaidya, Vishwajit] Sure we could. But for any production change,
 I would have to offer a good enough reason.

What was the good enough reason to set those timeouts in the first place?

 Earlier posts related to this issue on the list seem to
 recommend tweaking: - several timeouts - JkOptions +DisableReuse
 This will require that every incoming HTTP connection opens up a
 new ajp13 connection to Tomcat. Your performance will totally suck
 if you enable this. But if it's the only way for you to get your
 application working properly, then I guess you'll have to do it. I
 suspect you /will not/ have to enable +DisableReuse.
 
 [Pantvaidya, Vishwajit] I was seeing earlier posts on this list
 mention some disagreement on the performance impact of setting
 +DisableReuse. Otherwise I would not even think of this.

+DisableReuse will, without a doubt, decrease your performance.

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

iEYEARECAAYFAkoRufgACgkQ9CaO5/Lv0PBGHwCfaOGjjv8A1wOAO0CrBKiMbVhM
9MEAoKD8QUbxfqd4h/8YcppkKAt2J1qM
=+kJC
-END PGP SIGNATURE-

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

Re: Problems configuring mod_jk

2009-05-18 Thread Gregor Schneider

Hi Rainer,

On Mon, May 18, 2009 at 9:35 PM, Rainer Jung rainer.j...@kippdata.de wrote:

 The error means: you told mod_jk to use it, but you forgot to define it.

 All vhost-definitions within Apache are alike when it comes to the
 jk-specs, thus I'm just posting a sample vhost-definition:

 VirtualHost *:443
     [ ...]

 Lots of mounts telling jk to use a worker named worker (the last token
 in the line)

     JkMount /SingleSignOnCLUE/* worker
     JkMount /LoginData/* worker

Oh my I'll have an appointment with an eye-specialist soon, promised...

You /definately/ shed some light here...

Thanks!

Gregor
-- 
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available
@ http://pgpkeys.pca.dfn.de:11371
@ http://pgp.mit.edu:11371/
skype:rc46fi

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

Re: Tomcat not closing threads

On 18.05.2009 16:43, Chetan Chheda wrote:
 Our network team is already engaged and looking into this. We had
 several instances of tomcats locking up today. I have attached one such
 thread dump here ..
  
 Can some of you pls take a look and point me into the right direction?

There are 149 Tomcat AJP pool threads connected to the web server and
waiting for the next request in their connection (and one additional
thread waiting for the next connection).

I assume the size of your Tomcat AJP connection pool is 150 and so your
pool is exhausted. See my coming up answer to your other posts.

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

Re: MAX Simultaneous connections with Tomcat on Windows XP Pro

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Arijit,

On 5/18/2009 3:12 PM, Arijit Sarkar Job Gmail wrote:
 This link on Microsoft specifies this very issue.. 
 http://support.microsoft.com/kb/314882

Interesting:


For Windows XP Professional, the maximum number of other computers that
are permitted to simultaneously connect over the network is ten. This
limit includes all transports and resource sharing protocols /combined/.

(emphasis mine)

  The connection limit refers to the number of redirector-based
 connections and is enforced for any file, print, named pipe, or mail
 slot session. The TCP connection limit is not enforced, but it may be
 bound by legal agreement to not permit more than 10 clients. 
 
 Doesn’t this solidify our point that the connection limit is not for
 Http connections?

I'm pretty sure that's true, although if you were using the ISAPI
redirector to connect Tomcat to IIS, you could almost certainly be
subject to these connection limits.

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

iEYEARECAAYFAkoRvXQACgkQ9CaO5/Lv0PBJnwCeJzWRIEyQBU8DxGih6F4aE5FX
dpEAoIW5bGAA8mWGo+o/1ZpRMha9TNhC
=/mn0
-END PGP SIGNATURE-

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

RE: Tomcat not closing threads


good to know
With worker mpm the connection_pool_size defaults to ThreadsPerChild
ThreadsPerChild that in the final gives the MaxClients connections to the 
Tomcat.
So the default value for connection_pool_size is always ThreadsPerChild

For threaded and hybrid servers (e.g. beos
or worker) MaxClients restricts
the total number of threads that will be available to serve clients.
The default value for beos is 50. 
For
hybrid MPMs the default value is 16 (ServerLimit) multiplied by the value of
25 (ThreadsPerChild). Therefore, to increase MaxClients to a value that 
requires more than 16 processes,
you must also raise ServerLimit.
/***in your case***/
(MaxClients)MaxClients=16(ServerLimit)*256(ThreadsPerChild)=4096

onto thread calculation:

Description:Minimum number of idle threads available to handle request
spikes
Syntax:MinSpareThreads number
Default:See usage for details
Context:server config
Status:MPM
Module:beos, mpm_netware, mpmt_os2, worker

Minimum number of idle threads to handle request spikes.
Different MPMs deal with this directive
differently.



worker
 uses a default of MinSpareThreads
75 and deal with idle threads on a server-wide basis. If
there aren't enough idle threads in the server then child
processes are created until the number of idle threads is greater
than number.


mpm_netware uses a default of
MinSpareThreads 10 and, since it is a single-process
MPM, tracks this on a server-wide bases.


beos and mpmt_os2 work
similar to mpm_netware. The default for
beos is MinSpareThreads 1. For
mpmt_os2 the default value is 5.
/*lets assume you havent touched this and MinSpareThreads stays at 
75***/
MaxSpareThreads(this is the parameter that is plaguing your environment)

The range of the MaxSpareThreads value
  is restricted. Apache will correct the given value automatically
  according to the following rules:

  perchild requires MaxSpareThreads to be less or equal than 
ThreadLimit.mpm_netware wants the value to be greater than
MinSpareThreads.For leader, threadpool and
worker the value must be greater or equal than
the sum of MinSpareThreads
and ThreadsPerChild.
MaxSpareThreads = MinSpareThreads+ThreadsPerChild
MaxSpareThreads =75+256
MaxSpareThreads must be = 331

after all that if you still dont have enough SpareThreads i would up (master 
thread limit) ThreadLimit to the max
The default value for ThreadLimit is
1920 when used with mpm_winnt and
64 when used with the others.



There is a hard limit of ThreadLimit 2 (or
  ThreadLimit 15000 with mpm_winnt)
  compiled into the server. This is intended to avoid nasty effects
  caused by typos.

/conceivable to start with 1920 and increase by increments of 500 until 
number of threads sufficient ***/
BTW: the ceiling on ThreadLimit=15000

In your case 
ThreadLimit=1920

HTH
Martin Gainty 
__ 
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und 
Vertraulichkeitanmerkung/Note de déni et de confidentialité
 Ez az
üzenet bizalmas.  Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
készítése nem megengedett.  Ez az üzenet csak ismeret cserét szolgál és
semmiféle jogi alkalmazhatósága sincs.  Mivel az electronikus üzenetek
könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
ezen üzenet tartalma miatt.

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




 Date: Mon, 18 May 2009 12:03:35 -0700
 From: chetan_chh...@yahoo.com
 Subject: Re: Tomcat not closing threads
 To: users@tomcat.apache.org
 
 Apache is using worker mpm 
 Server version: Apache/2.0.59  HP-UX_Apache-based_Web_Server
 Server built:   Aug 21 2007 13:59:06
 Server's Module Magic Number: 20020903:12
 Server loaded:  APR 0.9.12, APR-UTIL 0.9.12
 Compiled using: APR 0.9.12, APR-UTIL 0.9.12
 Architecture:   64-bit
 Server compiled with
  -D APACHE_MPM_DIR=server/mpm/worker

RE: never mind :)

congratulations a previously unsolved mystery has been solved

what was the solution?
Martin Gainty
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Date: Mon, 18 May 2009 14:36:54 -0500
Subject: never mind :)
From: w...@serensoft.com
To: users@tomcat.apache.org

We just got Tomcat 5 to work as a service on windows 64-bit, woo hoo!
(see email with subject running tomcat5 -- as a service under 64-bit
windows? SOLVED.)

We thought we had another new snag, but there's just a firewall or
network issue.

We now return you to your regularly scheduled email. :)

--
will trillich
Our only real economic security lies in our power to meet human
needs. -- S.Covey, the 8th Habit

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

_
Hotmail® has ever-growing storage! Don’t worry about storage limits.
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009

Re: Tomcat not closing threads

On 18.05.2009 20:03, Chetan Chheda wrote:
 HTTPd.conf : 
 Timeout 300
 KeepAlive On
 MaxKeepAliveRequests 100
 KeepAliveTimeout 30

HTTP Keep-Alive is nice to achieve lower latency, but it will drive up
the number of httpd threads you need. 100 requests and 20 seconds is for
most use cases to expensive (in terms of needed threads), I would
suggest a KeepAliveTimeout closer to e.g. 5 seconds.

 IfModule worker.c
 ThreadLimit512
 StartServers   100 
 MaxClients 512 
 MinSpareThreads129 
 MaxSpareThreads256 
 ThreadsPerChild256 
 MaxRequestsPerChild  0
 /IfModule

Apache scales via processes. You chose to size the number of thread per
process to a much higher value than default. That means whenever Apache
starts an additional process, you add a lot of additional threads at
once. That's not a very fine granular scaling. Furthermore the
combination of 100 processes to start with, each with 256 threads, but a
total limit of 512 parallel connections does not make sense. Read
carefully through the httpd documentation what these parameters mean and
how they interact. Also be sure to have anough delta between Min and Max
SpareThrads in terms of multiples of ThreadsPerChild. Otherwise you'll
be very often starting and stopping Apache processes.

From now on I Assume you find better values, but still go for a maximum
concurrency of 512 http connections.

Which version of mod_jk do you use (strings mod_jk.so | grep 1.2)? Does
HP now provide a recent one? The below attribute names indicate a very
old mod_jk.

Comments below the lines.

 Workers.properties: 
 njipuplmapp01:/opt/hpws/apache/conf#cat workers.properties
 ps=/

Delete

 workers.tomcat_home=/coach/app/ptc/tomcat1

Delete

 worker.list=ajp13App11,ajp13App12,loadbalancer,mystatus
 worker.ajp13App11.port=8010
 worker.ajp13App11.host=localhost
 worker.ajp13App11.type=ajp13
 worker.ajp13App11.lbfactor=1
 worker.ajp13App11.cache_timeout=900

Read the docs page about timeouts and set your Tomcat connectionTimeout
consistently.

 worker.ajp13App11.socket_timeout=0

I personally don't like the socket_timeout, but much more cping/cpong
timeouts.

 worker.ajp13App11.retries=3
 worker.ajp13App11.recycle_timeout=900
 
 worker.ajp13App12.port=8011
 worker.ajp13App12.host=localhost
 worker.ajp13App12.type=ajp13
 worker.ajp13App12.lbfactor=1
 worker.ajp13App12.cache_timeout=900
 worker.ajp13App12.socket_timeout=0
 worker.ajp13App12.retries=3
 worker.ajp13App12.recycle_timeout=900
 
 worker.loadbalancer.type=lb
 worker.loadbalancer.balanced_workers=ajp13App11,ajp13App12
 worker.loadbalancer.method=Request
 worker.loadbalancer.sticky_session=true
 
 worker.inprocess.class_path=$(workers.tomcat_home)$(ps)lib$(ps)tomcat.jar
 worker.inprocess.cmd_line=start
 worker.inprocess.stdout=$(workers.tomcat_home)$(ps)logs$(ps)inprocess.stdout
 worker.inprocess.stderr=$(workers.tomcat_home)$(ps)logs$(ps)inprocess.stderr

Delete those three attributes.

 worker.mystatus.type=status
 worker.mystatus.mount=/admin/status/jk
 
 mod_jk 
 # Configure mod_jk for basic operation
 IfModule mod_jk.c
   JkWorkersFile conf/workers.properties
   JkLogFile logs/mod_jk.log
   JkLogLevel info
   JkShmFile logs/JkShmFile.log
   
   # Must use this for proper % escaping (cannot use with Tomcat 3.2.x)
   JkOptions +ForwardURIEscaped
   # Uncomment the line below once HP builds with mod_jk 1.2.13 or
   # higher to ensure that the 'X-Do-not-compress-this' header
   # behaves as expected.
   #JkOptions +FlushPackets
   
   # Mount all JSP pages with our default worker
   JkMount /*.jsp loadbalancer
   JkMount /*.jsp/* loadbalancer
 /IfModule
 
 Connector :
 Connector acceptCount=100 connectionTimeout=2 
 disableUploadTimeout=true port=8082 redirectPort=8445 
 maxSpareThreads=75 maxThreads=150 minSpareThreads=25
 /Connector
 Connector URIEncoding=UTF-8 acceptCount=100 debug=1 port=8012 
 protocol=AJP/1.3 
 protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler 
 redirectPort=8445 tomcatAuthentication=false useBodyEncodingForURI=true

Set number of threads (you'll need a maximum of 512, if your web servers
are allowed with 512 connections forwarding to Tomcat)
and also connectionTimeout!

 /Connector

Regards,

Rainer

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

Re: never mind :)

2009-05-18 Thread will trillich

Tomcat is listening on 0.0.0.0:80 but not responding on the public
interface. Works fine for localhost and the 10.*.*.* address, but not
the public IP.

Can't say it's been solved, but it's not a tomcat issue, there's
something else gone awry.

On Mon, May 18, 2009 at 3:02 PM, Martin Gainty mgai...@hotmail.com wrote:
congratulations a previously unsolved mystery has been solved

what was the solution?
Martin Gainty
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich
dem Austausch von Informationen und entfaltet keine rechtliche
Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen
wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci
est interdite. Ce message sert à l'information seulement et n'aura pas
n'importe quel effet légalement obligatoire. Étant donné que les email
peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
aucune responsabilité pour le contenu fourni.

Date: Mon, 18 May 2009 14:36:54 -0500
Subject: never mind :)
From: w...@serensoft.com
To: users@tomcat.apache.org

We just got Tomcat 5 to work as a service on windows 64-bit, woo hoo!
(see email with subject running tomcat5 -- as a service under 64-bit
windows? SOLVED.)

We thought we had another new snag, but there's just a firewall or
network issue.

We now return you to your regularly scheduled email. :)

--
will trillich
Our only real economic security lies in our power to meet human
needs. -- S.Covey, the 8th Habit

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

_
Hotmail® has ever-growing storage! Don’t worry about storage limits.
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009

--
will trillich
Our only real economic security lies in our power to meet human
needs. -- S.Covey, the 8th Habit

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

Re: Problems configuring mod_jk

On 18.05.2009 21:51, Gregor Schneider wrote:
 Hi Rainer,
 
 On Mon, May 18, 2009 at 9:35 PM, Rainer Jung rainer.j...@kippdata.de wrote:
 The error means: you told mod_jk to use it, but you forgot to define it.

 All vhost-definitions within Apache are alike when it comes to the
 jk-specs, thus I'm just posting a sample vhost-definition:

 VirtualHost *:443
 [ ...]
 Lots of mounts telling jk to use a worker named worker (the last token
 in the line)

 JkMount /SingleSignOnCLUE/* worker
 JkMount /LoginData/* worker
 
 Oh my I'll have an appointment with an eye-specialist soon, promised...

No probs, I recently had one ;)

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

RE: Apache httpd vs Tomcat static content performance [Revised/Updated]

2009-05-18 Thread Robin Wilson

Thanks! This information isn't useless... Of course, more detailed results, 
after a longer test run would be more conclusive.

This appears to show that Apache is slightly faster (~4% or so) for files over 
16KiB than Tomcat APR, and materially faster (~44% or more) than all other 
configurations of Tomcat (especially for larger files).

Does that sync with your understanding as well?

--
Robin D. Wilson
Director of Web Development
KingsIsle Entertainment, Inc.
WORK: 512-623-5913
CELL: 512-426-3929
www.KingsIsle.com



-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Monday, May 18, 2009 2:31 PM
To: Tomcat Users List
Subject: Re: Apache httpd vs Tomcat static content performance [Revised/Updated]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

After reading some of your feedback, I've decided to make some changes:

- - Using TC 6.0.18 exclusively instead of 5.5
- - Using tcnative 1.1.16 instead of 1.1.12
- - Using httpd 2.2.11 instead of 2.2.10
- - Running tests for a certain amount of time instead of a
  certain number of requests

I have some preliminary results. Just as a smoke-test, I ran my tests
for 10 seconds each (10 seconds per file size, per server config) which
means that I can get a complete set of results in 15 minutes. The
results are borderline useless, but you can already start to see the
different configurations differentiate themselves:

File Size   Apache httpdCoyote  CoyoteAPR   
CoyoteAPR-sendfile  CoyoteNIO   CoyoteNIO–sendfile
4KiB4984.02 3833.73 5674.66 5433.23 
3128.34 3247.66
8KiB8795.03 7468.45 9465.31 10015.06
5616.81 5674.44
16KiB   15913.3812901.2116437.4016426.36
10316.2710171.56
32KiB   27525.0721270.0725361.0925557.25
17482.0917803.41
64KiB   47500.6132990.8138590.0237454.34
31113.9327034.23
128KiB  63920.7242161.1758548.6446011.54
7167.93 31891.99
256KiB  80030.0251749.2182274.4754119.36
256.29  34057.95
512KiB  95386.2745987.1589375.5249531.11
512.10  30722.53
1MiB105059.69   50127.8489988.7950886.45
1020.18 31309.67
2MiB99790.5651408.4195647.3844390.74
2032.38 32697.59
4MiB100633.551138.52105273.11   54729.79
4424.93 34088.29
8MiB99595.0351523.9298445.8356116.61
7936.50 32557.95
16MiB   99126.6551440.4598111.8255406.30
15400.8232681.28
32MiB   99018.9452719.7496605.4854410.23
28989.7533275.04

Quick setup: single localhost client (no concurrency), no keepalives, 10
second max samples per file size per server config.

I re-ran the NIO+sendfile tests afterward since the server was busy
(recompiling gcc as well as serving HTTP requests to whomever happens to
be using it right now) and I figured it was a fluke. The second test
showed the same results: NIO looks great until it hits the 128KiB file,
when it experiences a dramatic drop-off in performance. I'll have to
look into that: the NIO connector /without/ sendfile enabled does not
appear to suffer the same drop-off in performance (though it appears to
be the weakest contender in the bunch).

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

iEYEARECAAYFAkoRt2gACgkQ9CaO5/Lv0PCqZgCeN6zXJFY0E5kquz5//CsnaFGN
ZIwAn3b++7waMKoi9iJ2X0pyocKK7d/5
=UWiA
-END PGP SIGNATURE-

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

RE: Running out of tomcat threads - why many threads in RUNNABLE stage even with no activity


 [Pantvaidya, Vishwajit] Here are figures from 3 of the servers which have
 not yet run out of threads (so the thread count does not add up to 200). I
 have taken these late at night when no users are present, so I was
 expecting all threads to be Waiting for tomcat thread-pool.
 
 1. Total TP-Processor threads 48, Waiting 46, Runnable 2
 2. Total TP-Processor threads 40, Waiting 29, Runnable 11
 3. Total TP-Processor threads 120, Waiting 7, Runnable 113
 
 
 

[Pantvaidya, Vishwajit] Posting the thread dumps for the above 3 cases, since 
Rainer mentioned that he would like to see more of the stack trace.



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

Tomcat better on single or multi core?

2009-05-18 Thread johnrock


I will be deploying a spring/hibernate web app using Tomcat 6, dbcp and
MySql5.1.  I must decide on my initial tomcat dedicated deployment server
configuration and am looking for some advice:

(I am starting with one dedicated Tomcat server..will scale in time)

Based on budget, the affordable options I have to choose from appear to be:
1 single core @3Ghz 
or
1 dual core  @~2.1Ghz 
or 
1 Quad core @~2.1Ghz

My question is: Which processor configuration do you think would benefit
tomcat more? Given the limited/basic options I have,would tomcat benefit
more from 2 or more cores or is speed more important?
-- 
View this message in context: 
http://www.nabble.com/Tomcat-better-on-single-or-multi-core--tp23604529p23604529.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


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

Re: Apache httpd vs Tomcat static content performance [Revised/Updated]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robin,

On 5/18/2009 4:11 PM, Robin Wilson wrote:
 Thanks! This information isn't useless... Of course, more detailed
 results, after a longer test run would be more conclusive.

Yup, that's the plan. Tonight, I'll be running with an 8 minute test to
give me 12 solid hours of testing. /Those/ should be more definitive
results. I've also rigged my test to prime the server by hitting each
file a single time, then waiting a few seconds, then starting the real test.

 This appears to show that Apache is slightly faster (~4% or so) for
 files over 16KiB than Tomcat APR, and materially faster (~44% or
 more) than all other configurations of Tomcat (especially for larger
 files).

Tomcat+APR is so close to httpd as to be in a dead heat as far as I'm
concerned. We'll know more once the larger-scale tests have been run. If
you graph these numbers (or read very carefully), you can see that
Coyote+APR outperforms httpd for two of the samples.

Also, the APR connector without sendfile is basically the same as using
the simple Coyote connector. I suspect the same is true of the NIO
connector, though it uses a different strategy for reading and writing,
obviously.

Something is obviously amiss with sendfile-enabled NIO connector,
though. Suggestions from those who know would be appreciated.

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

iEYEARECAAYFAkoRxCEACgkQ9CaO5/Lv0PBw1QCgs4g8fZk4ESSC7dDpVEZoAnah
HmQAoJk7FshdtZlboIG+niTRy0Lb5zRP
=6B0w
-END PGP SIGNATURE-

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

RE: Running out of tomcat threads - why many threads in RUNNABLEstage even with no activity

 From: Pantvaidya, Vishwajit [mailto:vpant...@selectica.com]
 Subject: RE: Running out of tomcat threads - why many threads in
 RUNNABLEstage even with no activity

 [Pantvaidya, Vishwajit] Posting the thread dumps for the above 3 cases,

The list usually filters out attachments, as it has done with yours.  Either 
put them on a publicly accessible web site, or right in the text of the e-mail.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

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

RE: Tomcat better on single or multi core?

 From: johnrock [mailto:johnpi...@yahoo.com]
 Subject: Tomcat better on single or multi core?

 Which processor configuration do you think would
 benefit tomcat more?

It's not Tomcat you have to think about - it's your webapp, and the expected 
usage thereof.  If the webapp is CPU bound but will be run with limited 
concurrency, the faster single core *may* be better.  If you expect lots of 
concurrency but still with significant CPU usage, then more cores will help.  
If you're I/O bound (including DB access), then it's unlikely the CPU 
configuration will matter much.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

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

Re: Tomcat better on single or multi core?

2009-05-18 Thread George Sexton

You haven't given any pricing information. I guess if it were me and the 
prices were all equal, I would go for the Quad-Core. If prices were not 
equal, I would go for the dual core.




johnrock wrote:

I will be deploying a spring/hibernate web app using Tomcat 6, dbcp and
MySql5.1.  I must decide on my initial tomcat dedicated deployment server
configuration and am looking for some advice:

(I am starting with one dedicated Tomcat server..will scale in time)

Based on budget, the affordable options I have to choose from appear to be:
1 single core @3Ghz 
or
1 dual core  @~2.1Ghz 
or 
1 Quad core @~2.1Ghz


My question is: Which processor configuration do you think would benefit
tomcat more? Given the limited/basic options I have,would tomcat benefit
more from 2 or more cores or is speed more important?
  


--
George Sexton
MH Software, Inc.
Voice: +1 303 438 9585
URL:   http://www.mhsoftware.com/


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

Changing default context path

2009-05-18 Thread Yaakov Chaikin

Hi,

I am trying to deploy a WAR with a custom context path. For some reason,
Tomcat still defaults to the WAR file name as the context path...

What I am doing is placing context.xml inside the blah.war under
META-INF/context.xml. Here are the contents of context.xml:
**
?xml version=1.0 encoding=UTF-8?

Context path=/test /
***

For some reason, Tomcat still deploys the blah.war application to /blah, not
to /test.

RE: Apache httpd vs Tomcat static content performance [Revised/Updated]

2009-05-18 Thread Robin Wilson

I don't know if I'd call a 4% difference a dead heat... I guess that would 
depend on how many of those files you are serving a day... If I had 25 servers 
all working full-throttle all day, 4% would be enough to require 1 more server. 
If my peak load exceeds the necessary threshold, 4% could mean I get end-users 
seeing errors periodically through the day - even with much smaller 
configurations.

Just something to think about...

--
Robin D. Wilson
Director of Web Development
KingsIsle Entertainment, Inc.
WORK: 512-623-5913
CELL: 512-426-3929
www.KingsIsle.com



-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Monday, May 18, 2009 3:25 PM
To: Tomcat Users List
Subject: Re: Apache httpd vs Tomcat static content performance [Revised/Updated]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robin,

On 5/18/2009 4:11 PM, Robin Wilson wrote:
 Thanks! This information isn't useless... Of course, more detailed
 results, after a longer test run would be more conclusive.

Yup, that's the plan. Tonight, I'll be running with an 8 minute test to
give me 12 solid hours of testing. /Those/ should be more definitive
results. I've also rigged my test to prime the server by hitting each
file a single time, then waiting a few seconds, then starting the real test.

 This appears to show that Apache is slightly faster (~4% or so) for
 files over 16KiB than Tomcat APR, and materially faster (~44% or
 more) than all other configurations of Tomcat (especially for larger
 files).

Tomcat+APR is so close to httpd as to be in a dead heat as far as I'm
concerned. We'll know more once the larger-scale tests have been run. If
you graph these numbers (or read very carefully), you can see that
Coyote+APR outperforms httpd for two of the samples.

Also, the APR connector without sendfile is basically the same as using
the simple Coyote connector. I suspect the same is true of the NIO
connector, though it uses a different strategy for reading and writing,
obviously.

Something is obviously amiss with sendfile-enabled NIO connector,
though. Suggestions from those who know would be appreciated.

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

iEYEARECAAYFAkoRxCEACgkQ9CaO5/Lv0PBw1QCgs4g8fZk4ESSC7dDpVEZoAnah
HmQAoJk7FshdtZlboIG+niTRy0Lb5zRP
=6B0w
-END PGP SIGNATURE-

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

RE: Changing default context path

 From: Yaakov Chaikin [mailto:yaakov.chai...@gmail.com]
 Subject: Changing default context path

 Tomcat still defaults to the WAR file name as the context path...

That's how it's defined to work.  The path attribute is not allowed except in 
circumstances that are strongly discouraged.  Change the name of your .war file.

 - 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: Apache httpd vs Tomcat static content performance [Revised/Updated]

2009-05-18 Thread Peter Lin

If you need to serve static files for a high volume website, you're
better off paying a specialty provider for it. Back when I worked at
verizon, we used Akamai for static files like images etc.

serving up a ton of large static files quickly swamps your bandwidth,
so the question isn't whether that 4% matters. It's really about how
much bandwidth you're chewing up with static data. Unless the servers
are hosted at a Tier 1 provider with OC12 bandwidth or higher, it
really isn't going to make any difference from my experience.

peter

On Mon, May 18, 2009 at 4:34 PM, Robin Wilson rwil...@kingsisle.com wrote:
 I don't know if I'd call a 4% difference a dead heat... I guess that would 
 depend on how many of those files you are serving a day... If I had 25 
 servers all working full-throttle all day, 4% would be enough to require 1 
 more server. If my peak load exceeds the necessary threshold, 4% could mean I 
 get end-users seeing errors periodically through the day - even with much 
 smaller configurations.

 Just something to think about...

 --
 Robin D. Wilson
 Director of Web Development
 KingsIsle Entertainment, Inc.
 WORK: 512-623-5913
 CELL: 512-426-3929
 www.KingsIsle.com



 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Monday, May 18, 2009 3:25 PM
 To: Tomcat Users List
 Subject: Re: Apache httpd vs Tomcat static content performance 
 [Revised/Updated]

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Robin,

 On 5/18/2009 4:11 PM, Robin Wilson wrote:
 Thanks! This information isn't useless... Of course, more detailed
 results, after a longer test run would be more conclusive.

 Yup, that's the plan. Tonight, I'll be running with an 8 minute test to
 give me 12 solid hours of testing. /Those/ should be more definitive
 results. I've also rigged my test to prime the server by hitting each
 file a single time, then waiting a few seconds, then starting the real test.

 This appears to show that Apache is slightly faster (~4% or so) for
 files over 16KiB than Tomcat APR, and materially faster (~44% or
 more) than all other configurations of Tomcat (especially for larger
 files).

 Tomcat+APR is so close to httpd as to be in a dead heat as far as I'm
 concerned. We'll know more once the larger-scale tests have been run. If
 you graph these numbers (or read very carefully), you can see that
 Coyote+APR outperforms httpd for two of the samples.

 Also, the APR connector without sendfile is basically the same as using
 the simple Coyote connector. I suspect the same is true of the NIO
 connector, though it uses a different strategy for reading and writing,
 obviously.

 Something is obviously amiss with sendfile-enabled NIO connector,
 though. Suggestions from those who know would be appreciated.

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

 iEYEARECAAYFAkoRxCEACgkQ9CaO5/Lv0PBw1QCgs4g8fZk4ESSC7dDpVEZoAnah
 HmQAoJk7FshdtZlboIG+niTRy0Lb5zRP
 =6B0w
 -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: Problems configuring mod_jk

2009-05-18 Thread André Warnier


Gregor,

Gregor Schneider wrote:

Hi guys,

I'm about to update an old Tomcat-instance (5.5.quite_old) to the
latest 5.5, also I'm about to update an outdated mod_jk to the latest
version.

The old config of mod_jk had quite some depricated directions
included, so I changed them (opefully) according to the doc I found
here:http://tomcat.apache.org/connectors-doc/reference/workers.html

However, when I check the logs from mod_jk, I always get the following
error-messages (multiple times, I guess it's one for every virtual
host in Apache HTTPD):


Probably more like once for each Apache child/thread that starts.

(A VirtualHost in Apache is more like a personality, it's not really a 
process. Each child can impersonate any VirtualHost at each request.)




[2009-05-18 19:34:44][18754:3078399680] [error]
uri_worker_map_ext::jk_uri_worker_map.c (506): Could not find worker
with name 'worker' in uri map post proces
sing.

However, I do not see where I defined a worker with the name worker.


I see it, about 10 lines below this one.



All vhost-definitions within Apache are alike when it comes to the
jk-specs, thus I'm just posting a sample vhost-definition:

VirtualHost *:443
[ ...]

JkMount /SingleSignOnCLUE/* worker  --- right here for instance
JkMount /LoginData/* worker --- and here 
JkMount /j_security_check worker--- and so on..

JkMount /IndexCLUE/* worker
JkMount /BMIWizardCLUE/* worker
JkMount /RRWizardCLUE/* worker
JkMount /DiabetesCLUE/* worker
JkMount /HyperlipCLUE/* worker
JkMount /ForeignTravelCLUE/* worker
JkMount /MartialArtsCLUE/* worker
#
JkRequestLogFormat %b %m %q %s %T

[ ...]
/VirtualHost

My jk.conf:

JkWorkersFile /etc/apache2/workers.properties
JkLogFile |/usr/bin/cronolog -S/var/log/apache2/mod_jk.log
/var/log/apache2/%Y/%m/mod_jk-%d.log
JkLogLevel info
JkLogStampFormat [%F %T]


And here come my workers.properties:

# workers.properties - ajp13
#
# List workers
worker.list=wrkr   --  that's the mismatch with above
# Define wrkr
worker.wrkr.port=8009
worker.wrkr.host=127.0.0.1
worker.wrkr.type=ajp13
worker.wrkr.connection_pool_size=30
worker.wrkr.connection_pool_timeout=60
worker.wrkr.socket_timeout=60
worker.wrkr.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=wrkr



So either you replace worker by wrkr in your JkMount's, or 
vice-versa replace wrkr by worker in workers.properties.





Versions I'm using:

Using CATALINA_BASE:   /home/tomcat/www
Using CATALINA_HOME:   /home/tomcat/www
Using CATALINA_TMPDIR: /home/tomcat/www/temp
Using JRE_HOME:   /opt/jdk1.5
Server version: Apache Tomcat/5.5.27
Server built:   Aug 28 2008 10:08:26
Server number:  5.5.27.0
OS Name:Linux
OS Version: 2.6.18-5-686
Architecture:   i386
JVM Version:1.5.0_07-b03
JVM Vendor: Sun Microsystems Inc.

Server version: Apache/2.2.3
Server built:   Sep  6 2008 09:52:20

OS is debian etch, kernel is  2.6.18-5-686 GNU/Linux

Would be great if anyone could shed some light...

TIA

Gregor



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

RE: Apache httpd vs Tomcat static content performance[Revised/Updated]

 From: Robin Wilson [mailto:rwil...@kingsisle.com]
 Subject: RE: Apache httpd vs Tomcat static content
 performance[Revised/Updated]

 I don't know if I'd call a 4% difference a dead heat...

Given the likely variability of any measurements taken in an 8-second run, even 
10% or 15% would have to be considered noise at this point.  Also, platform 
variations (Chris' stuff is not state-of-the-art) may play a big role here, as 
does JVM level.  (HotSpot 1.6 is dramatically faster than 1.5 for *some* 
applications.)

Wait for the real numbers.  

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

RE: Apache httpd vs Tomcat static content performance [Revised/Updated]

 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Subject: Re: Apache httpd vs Tomcat static content performance
 [Revised/Updated]

 After reading some of your feedback, I've decided to make some changes:

 - - Using TC 6.0.18 exclusively instead of 5.5
 - - Using tcnative 1.1.16 instead of 1.1.12
 - - Using httpd 2.2.11 instead of 2.2.10
 - - Running tests for a certain amount of time instead of a
   certain number of requests

JVM version?

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

Re: Tomcat better on single or multi core?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John,

On 5/18/2009 4:17 PM, johnrock wrote:
 Based on budget, the affordable options I have to choose from appear to be:
 1 single core @3Ghz 
 or
 1 dual core  @~2.1Ghz 
 or 
 1 Quad core @~2.1Ghz

What are the types of cores? Are any of them hyperthreaded? Some of the
older Intel cores (like the P4) run at a high clock speed but aren't as
good as the newer, lower-speed cores. My Core2 Duo @ 2.1GHz beats the
crap out of my old P4 3.0GHz HT chip (same number of logical cores,
older one has higher clock speed rating).

 My question is: Which processor configuration do you think would benefit
 tomcat more? Given the limited/basic options I have,would tomcat benefit
 more from 2 or more cores or is speed more important?

Without going into too much detail (and risking flames!):

- - More logical cores are better than less
- - More physical cores are better than less (and better than more
  logical cores like hyperthreaded)
- - More physical CPUs aren't as good as multi-core chips with the
  same total number of cores (single chip sync'ing with itself
  is faster than reaching across the mobo to another chip
  to do the same thing)

Java web applications are, by definition, multi-threaded. The more
logical processing units you have, the faster your webapp will run,
since each core can only do one thing at a time!

In my experience, bus speed, memory speed, memory size, and disk speed
are the biggest differentiating factors for servers. Let's face it: your
web application is spending more time allocating, de-allocating, and
copying memory around than it is performing numerical computations. Most
of the time, your CPU is waiting on data to travel from one place to
another, not the other way around.

I would focus on factors other than the CPU, honestly.

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

iEYEARECAAYFAkoRx80ACgkQ9CaO5/Lv0PDIlACfUfuDHHH+tfR+Otv9hLMjIPc+
YGEAoIDZx8VX6lDp9PY5u3x1sE+cM5Ij
=feDA
-END PGP SIGNATURE-

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

Re: Changing default context path

2009-05-18 Thread Yaakov Chaikin

Hmm... the documentation seems to disagree with you:
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html

Take a look at 5th bullet.

I am just trying to figure out why that doesn't seem to work for me.

Yaakov.

On Mon, May 18, 2009 at 4:34 PM, Caldarale, Charles R 
chuck.caldar...@unisys.com wrote:

  From: Yaakov Chaikin [mailto:yaakov.chai...@gmail.com]
  Subject: Changing default context path
 
  Tomcat still defaults to the WAR file name as the context path...

 That's how it's defined to work.  The path attribute is not allowed except
 in circumstances that are strongly discouraged.  Change the name of your
 .war file.

  - 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: Running out of tomcat threads - why many threads in RUNNABLE stage even with no activity

  [Pantvaidya, Vishwajit] Here are figures from 3 of the servers which

 have

  not yet run out of threads (so the thread count does not add up to 200).

 I

  have taken these late at night when no users are present, so I was

  expecting all threads to be Waiting for tomcat thread-pool.

 

  1. Total TP-Processor threads 48, Waiting 46, Runnable 2

  2. Total TP-Processor threads 40, Waiting 29, Runnable 11

  3. Total TP-Processor threads 120, Waiting 7, Runnable 113

 

 

[Pantvaidya, Vishwajit] Since Rainer mentioned that he would like to see more 
of the stack trace, here are the complete stack traces for a Runnable and 
Waiting thread from #3 above. All Runnable/Waiting threads from all the above 
cases have same stack trace as below:



TP-Processor119 - Thread t...@2294

   java.lang.Thread.State: RUNNABLE

at java.net.SocketInputStream.socketRead0(Native Method)

at java.net.SocketInputStream.read(SocketInputStream.java:129)

at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)

at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)

at java.io.BufferedInputStream.read(BufferedInputStream.java:313)

at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:607)

at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:545)

at 
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:672)

at 
org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:876)

at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)

at java.lang.Thread.run(Thread.java:595)



TP-Processor118 - Thread t...@2293

   java.lang.Thread.State: WAITING on 
org.apache.tomcat.util.threads.threadpool$controlrunna...@3579cafe

at java.lang.Object.wait(Native Method)

at java.lang.Object.wait(Object.java:474)

at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:656)

at java.lang.Thread.run(Thread.java:595)

Re: running tomcat5 -- as a service under 64-bit windows?

2009-05-18 Thread will trillich

On Mon, May 18, 2009 at 2:12 PM, Mark Thomas ma...@apache.org wrote:
 When you install the service you have to name it tomcat5. It is a
 'feature' of that service wrapper that for a service XXX the binarie
 smust be named XXX.exe and XXXw.exe

Just learned this today:

if you install the tomcat service as service.bat install yadaboing
then you can configure it via tomcat5w //ES//yadaboing

Easy!

-- 
will trillich
Our only real economic security lies in our power to meet human
needs. -- S.Covey, the 8th Habit

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

RE: Changing default context path

 From: Yaakov Chaikin [mailto:yaakov.chai...@gmail.com]
 Subject: Re: Changing default context path

 Take a look at 5th bullet.

Take a look at the description of the path attribute, which you seem to be 
ignoring:

The value of this field must not be set except when statically defining a 
Context in server.xml, as it will be inferred from the filenames used for 
either the .xml context file or the docBase.

 I am just trying to figure out why that doesn't seem to work for me.

I already told you.  You need to read all of the doc, not just the parts that 
please you.

 - 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: running tomcat5 -- as a service under 64-bit windows?

 From: will trillich [mailto:trill...@gmail.com]
 Subject: Re: running tomcat5 -- as a service under 64-bit windows?

 if you install the tomcat service as service.bat install yadaboing
 then you can configure it via tomcat5w //ES//yadaboing

Or you can rename the tomcat5.exe and tomcat5w.exe files to yadaboing.exe and 
yadaboingw.exe, respectively.

 - 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: Apache httpd vs Tomcat static content performance [Revised/Updated]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

On 5/18/2009 4:40 PM, Caldarale, Charles R wrote:
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Subject: Re: Apache httpd vs Tomcat static content performance
 [Revised/Updated]

 After reading some of your feedback, I've decided to make some changes:

 - - Using TC 6.0.18 exclusively instead of 5.5
 - - Using tcnative 1.1.16 instead of 1.1.12
 - - Using httpd 2.2.11 instead of 2.2.10
 - - Running tests for a certain amount of time instead of a
   certain number of requests

 JVM version?

Still:

java version 1.6.0_13
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing)
(don't worry, I'll also test the -server VM)

I'll also be publishing /all/ config information when I actually publish
my findings.

Still default heap (turns out to be 64MB for my config).
Interesting that after all my little 10-second tests, the JVM has only
allocated 11MiB of its 64MiB max, and it's about 75% (8MiB) used right
now. I have all connectors configured simultaneously, each with their
own thread pools: Coyote/non-APR, Coyote/APR+sendfile,
Coyote/APR-sendfile, Coyote/NIO+sendfile, Coyote/NIO-sendfile. Most
connectors have allocated fewer than 5 request processor threads.

We'll see what happens when I crank-up the concurrency. I suspect we'll
see better things from the NIO connector, for instance.

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

iEYEARECAAYFAkoRyg4ACgkQ9CaO5/Lv0PCcfwCfbwyxHYGBisMZy83kzFwoI4Vx
JhQAni3uwBGhlOIVXf0JK7IYnZn0m3k0
=BWow
-END PGP SIGNATURE-

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

Re: Apache httpd vs Tomcat static content performance [Revised/Updated]

2009-05-18 Thread André Warnier


Chris, what do the numbers represent ?

You say you ran each test for 10 seconds, so I guess the numbers are not 
the seconds it took, so what are they ?


I also wonder about the numbers, for example in the first column 
(httpd).  They seem to grow more or less lineraly as the file size 
increases, but they at 512 KB they just level off.
It seems a bit counter-intutive that it would take the same whatever 
to serve 512KB files and 32MB ones.


André


Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

After reading some of your feedback, I've decided to make some changes:

- - Using TC 6.0.18 exclusively instead of 5.5
- - Using tcnative 1.1.16 instead of 1.1.12
- - Using httpd 2.2.11 instead of 2.2.10
- - Running tests for a certain amount of time instead of a
  certain number of requests

I have some preliminary results. Just as a smoke-test, I ran my tests
for 10 seconds each (10 seconds per file size, per server config) which
means that I can get a complete set of results in 15 minutes. The
results are borderline useless, but you can already start to see the
different configurations differentiate themselves:

File Size   Apache httpdCoyote  Coyote APR  Coyote APR -sendfile
Coyote
NIO Coyote NIO –sendfile
4KiB4984.02 3833.73 5674.66 5433.23 3128.34 3247.66
8KiB8795.03 7468.45 9465.31 10015.065616.81 5674.44
16KiB   15913.3812901.2116437.4016426.36
10316.2710171.56
32KiB   27525.0721270.0725361.0925557.25
17482.0917803.41
64KiB   47500.6132990.8138590.0237454.34
31113.9327034.23
128KiB  63920.7242161.1758548.6446011.547167.93 
31891.99
256KiB  80030.0251749.2182274.4754119.36256.29  
34057.95
512KiB  95386.2745987.1589375.5249531.11512.10  
30722.53
1MiB105059.69   50127.8489988.7950886.451020.18 
31309.67
2MiB99790.5651408.4195647.3844390.742032.38 
32697.59
4MiB100633.551138.52105273.11   54729.794424.93 
34088.29
8MiB99595.0351523.9298445.8356116.617936.50 
32557.95
16MiB   99126.6551440.4598111.8255406.30
15400.8232681.28
32MiB   99018.9452719.7496605.4854410.23
28989.7533275.04

Quick setup: single localhost client (no concurrency), no keepalives, 10
second max samples per file size per server config.

I re-ran the NIO+sendfile tests afterward since the server was busy
(recompiling gcc as well as serving HTTP requests to whomever happens to
be using it right now) and I figured it was a fluke. The second test
showed the same results: NIO looks great until it hits the 128KiB file,
when it experiences a dramatic drop-off in performance. I'll have to
look into that: the NIO connector /without/ sendfile enabled does not
appear to suffer the same drop-off in performance (though it appears to
be the weakest contender in the bunch).

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

iEYEARECAAYFAkoRt2gACgkQ9CaO5/Lv0PCqZgCeN6zXJFY0E5kquz5//CsnaFGN
ZIwAn3b++7waMKoi9iJ2X0pyocKK7d/5
=UWiA
-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: Apache httpd vs Tomcat static content performance [Revised/Updated]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 5/18/2009 4:56 PM, André Warnier wrote:
 You say you ran each test for 10 seconds, so I guess the numbers are not
 the seconds it took, so what are they ?

They are transfer Rate (KiB/sec) as measured by ApacheBench.

 I also wonder about the numbers, for example in the first column
 (httpd).  They seem to grow more or less lineraly as the file size
 increases, but they at 512 KB they just level off.
 It seems a bit counter-intutive that it would take the same whatever
 to serve 512KB files and 32MB ones.

I suspect it is one of two things:

1. At ~512KiB the time to serve the files begins to dominate the time
   while smaller files are being dominated by the time to open them

2. The HTTP headers are not being considered in the transfer rate

I think #2 is less likely, since the smallest file I'm working with is
4KiB and I suspect less than 1KiB is being taken up with HTTP headers.
If #2 were the culprit, I would have expected the inflection point to be
much earlier.

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

iEYEARECAAYFAkoRzvcACgkQ9CaO5/Lv0PALqQCfb5Bz1iMIoHUv+Lea/cIlKOTJ
lmUAnR8z+F8pgwW5qyl1tN/Hq7cPQpEN
=/Tsg
-END PGP SIGNATURE-

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

Re: Changing default context path

2009-05-18 Thread Yaakov Chaikin

On Mon, May 18, 2009 at 4:46 PM, Caldarale, Charles R
chuck.caldar...@unisys.com wrote:

  From: Yaakov Chaikin [mailto:yaakov.chai...@gmail.com]
  Subject: Re: Changing default context path

  Take a look at 5th bullet.

 Take a look at the description of the path attribute, which you seem to be 
 ignoring:

 The value of this field must not be set except when statically defining a 
 Context in server.xml, as it will be inferred from the filenames used for 
 either the .xml context file or the docBase.

Oops... I guess, I missed that part... But it does say that the
context path is inferred from .xml context file... So, is it telling
me that I can place bla.xml into META-INF directory with a Context/
tag in it and the context path will change to /bla? I tried that and
it didn't work.

So, are you saying that there is NO way (outside of configuring a
Context... inside the server.xml) to have the name of the WAR file
be one thing and the context path be something else? I am looking for
a way to carry the context path information inside the WAR itself due
to my build process requirements.

 I already told you.  You need to read all of the doc, not just the parts that 
 please you.

Ouch. Man! Lower you weapon. Just asking a question. (I did have the
audacity of missing part of the documentation.)

Thanks for your help,
Yaakov.

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

Re: Running out of tomcat threads - why many threads in RUNNABLE stage even with no activity

Yes, those two look like waiting for next request on an existing
connection from the web server to Tomcat and sitting idle in the pool,
waiting for a new connection to handle.

On 18.05.2009 22:44, Pantvaidya, Vishwajit wrote:
 [Pantvaidya, Vishwajit] Here are figures from 3 of the servers which
 
 have
 
 not yet run out of threads (so the thread count does not add up to 200).
 
 I
 
 have taken these late at night when no users are present, so I was
 
 expecting all threads to be Waiting for tomcat thread-pool.
 
 
 1. Total TP-Processor threads 48, Waiting 46, Runnable 2
 
 2. Total TP-Processor threads 40, Waiting 29, Runnable 11
 
 3. Total TP-Processor threads 120, Waiting 7, Runnable 113
 
 
 
 [Pantvaidya, Vishwajit] Since Rainer mentioned that he would like to see more 
 of the stack trace, here are the complete stack traces for a Runnable and 
 Waiting thread from #3 above. All Runnable/Waiting threads from all the above 
 cases have same stack trace as below:
 
 
 
 TP-Processor119 - Thread t...@2294
 
java.lang.Thread.State: RUNNABLE
 
 at java.net.SocketInputStream.socketRead0(Native Method)
 
 at java.net.SocketInputStream.read(SocketInputStream.java:129)
 
 at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
 
 at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
 
 at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
 
 at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:607)
 
 at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:545)
 
 at 
 org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:672)
 
 at 
 org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:876)
 
 at 
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
 
 at java.lang.Thread.run(Thread.java:595)
 
 
 
 TP-Processor118 - Thread t...@2293
 
java.lang.Thread.State: WAITING on 
 org.apache.tomcat.util.threads.threadpool$controlrunna...@3579cafe
 
 at java.lang.Object.wait(Native Method)
 
 at java.lang.Object.wait(Object.java:474)
 
 at 
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:656)
 
 at java.lang.Thread.run(Thread.java:595)
 

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

Re: Tomcat not closing threads

Hi martin, 

 Thanks for your reply but you have left me confused 

Since Apache is setup as below 
Maxclients = 512 
ThreadsPerChild = 256

Wont it restrict the processes to 2 processes with 256 threads each instead of 
the ServerLimit(16) ? Looking at the OS , I see 2 httpd processes each with 258 
threads 

Thanks,
Chetan



From: Martin Gainty mgai...@hotmail.com
To: Tomcat Users List users@tomcat.apache.org
Sent: Monday, May 18, 2009 4:00:16 PM
Subject: RE: Tomcat not closing threads


good to know
With worker mpm the connection_pool_size defaults to ThreadsPerChild
ThreadsPerChild that in the final gives the MaxClients connections to the 
Tomcat.
So the default value for connection_pool_size is always ThreadsPerChild

For threaded and hybrid servers (e.g. beos
    or worker) MaxClients restricts
    the total number of threads that will be available to serve clients.
    The default value for beos is 50. 
For
    hybrid MPMs the default value is 16 (ServerLimit) multiplied by the value of
    25 (ThreadsPerChild). Therefore, to increase MaxClients to a value that 
requires more than 16 processes,
    you must also raise ServerLimit.
/***in your case***/
(MaxClients)MaxClients=16(ServerLimit)*256(ThreadsPerChild)=4096

onto thread calculation:

Description:Minimum number of idle threads available to handle request
spikes
Syntax:MinSpareThreads number
Default:See usage for details
Context:server config
Status:MPM
Module:beos, mpm_netware, mpmt_os2, worker

    Minimum number of idle threads to handle request spikes.
    Different MPMs deal with this directive
    differently.



    worker
    uses a default of MinSpareThreads
    75 and deal with idle threads on a server-wide basis. If
    there aren't enough idle threads in the server then child
    processes are created until the number of idle threads is greater
    than number.


    mpm_netware uses a default of
    MinSpareThreads 10 and, since it is a single-process
    MPM, tracks this on a server-wide bases.


    beos and mpmt_os2 work
    similar to mpm_netware. The default for
    beos is MinSpareThreads 1. For
    mpmt_os2 the default value is 5.
/*lets assume you havent touched this and MinSpareThreads stays at 
75***/
MaxSpareThreads(this is the parameter that is plaguing your environment)

The range of the MaxSpareThreads value
      is restricted. Apache will correct the given value automatically
      according to the following rules:

      perchild requires MaxSpareThreads to be less or equal than 
ThreadLimit.mpm_netware wants the value to be greater than
        MinSpareThreads.For leader, threadpool and
        worker the value must be greater or equal than
        the sum of MinSpareThreads
        and ThreadsPerChild.
MaxSpareThreads = MinSpareThreads+ThreadsPerChild
MaxSpareThreads =75+256
MaxSpareThreads must be = 331

after all that if you still dont have enough SpareThreads i would up (master 
thread limit) ThreadLimit to the max
The default value for ThreadLimit is
    1920 when used with mpm_winnt and
    64 when used with the others.



    There is a hard limit of ThreadLimit 2 (or
      ThreadLimit 15000 with mpm_winnt)
      compiled into the server. This is intended to avoid nasty effects
      caused by typos.

    /conceivable to start with 1920 and increase by increments of 500 until 
number of threads sufficient ***/
BTW: the ceiling on ThreadLimit=15000

In your case 
ThreadLimit=1920

HTH
Martin Gainty 
__ 
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und 
Vertraulichkeitanmerkung/Note de déni et de confidentialité
Ez az
üzenet bizalmas.  Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
készítése nem megengedett.  Ez az üzenet csak ismeret cserét szolgál és
semmiféle jogi alkalmazhatósága sincs.  Mivel az electronikus üzenetek
könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
ezen üzenet tartalma miatt.

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.

Re: Changing default context path

2009-05-18 Thread Pid

Caldarale, Charles R wrote:
 The path attribute is not allowed except in circumstances that are strongly 
 discouraged.  

Can I suggest an amendment to the documentation as follows:

- If you specify a context path of an empty string (), you are
- defining the default web application for this Host, which will

+ If you specify a context path you must be able to prove the Riemann
+ hypothesis.


p




  - 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: Running out of tomcat threads - why many threads in RUNNABLE stage even with no activity

 -Original Message-
 From: Rainer Jung [mailto:rainer.j...@kippdata.de]
 Sent: Monday, May 18, 2009 2:43 PM
 To: Tomcat Users List
 Subject: Re: Running out of tomcat threads - why many threads in RUNNABLE
 stage even with no activity

 Yes, those two look like waiting for next request on an existing
 connection from the web server to Tomcat and sitting idle in the pool,
 waiting for a new connection to handle.

[Pantvaidya, Vishwajit] Thanks Rainier. Any idea why threads would be sitting 
around in Runnable state even when nobody has been using application for a long 
time. From whatever I have read on this, it seems to me that this could happen 
if a servlet writes something to a response stream, closes the response stream, 
but after that keeps on doing some processing (e.g. running an infinite loop). 
I am reasonably sure that our app is not doing something like that. Unless 
there was something like an infinite loop running in a servlet, I would assume 
that the servlet would eventually return and the tomcat TP-Processor thread 
would be released back to the connection pool (go into Waiting state).

 On 18.05.2009 22:44, Pantvaidya, Vishwajit wrote:
  [Pantvaidya, Vishwajit] Here are figures from 3 of the servers which

  have

  not yet run out of threads (so the thread count does not add up to
 200).

  I

  have taken these late at night when no users are present, so I was

  expecting all threads to be Waiting for tomcat thread-pool.

  1. Total TP-Processor threads 48, Waiting 46, Runnable 2

  2. Total TP-Processor threads 40, Waiting 29, Runnable 11

  3. Total TP-Processor threads 120, Waiting 7, Runnable 113

  [Pantvaidya, Vishwajit] Since Rainer mentioned that he would like to see
 more of the stack trace, here are the complete stack traces for a Runnable
 and Waiting thread from #3 above. All Runnable/Waiting threads from all
 the above cases have same stack trace as below:

  TP-Processor119 - Thread t...@2294

 java.lang.Thread.State: RUNNABLE

  at java.net.SocketInputStream.socketRead0(Native Method)

  at java.net.SocketInputStream.read(SocketInputStream.java:129)

  at
 java.io.BufferedInputStream.fill(BufferedInputStream.java:218)

  at
 java.io.BufferedInputStream.read1(BufferedInputStream.java:256)

  at
 java.io.BufferedInputStream.read(BufferedInputStream.java:313)

  at
 org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:607)

  at
 org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:545)

  at
 org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:67
 2)

  at
 org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.ja
 va:876)

  at
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.j
 ava:684)

  at java.lang.Thread.run(Thread.java:595)

  TP-Processor118 - Thread t...@2293

 java.lang.Thread.State: WAITING on
 org.apache.tomcat.util.threads.threadpool$controlrunna...@3579cafe

  at java.lang.Object.wait(Native Method)

  at java.lang.Object.wait(Object.java:474)

  at
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.j
 ava:656)

  at java.lang.Thread.run(Thread.java:595)

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

RE: Changing default context path

 From: Yaakov Chaikin [mailto:yaakov.chai...@gmail.com]
 Subject: Re: Changing default context path

 So, is it telling me that I can place bla.xml into META-INF 
 directory with a Context/ tag in it and the context path
 will change to /bla? I tried that and it didn't work.

No, when inside the webapp, the Context element must be in 
META-INF/context.xml.

 So, are you saying that there is NO way (outside of configuring a
 Context... inside the server.xml) to have the name of the WAR file
 be one thing and the context path be something else?

You can keep the webapp outside of the Host appBase directory (Tomcat's 
webapps directory, by default), and place the Context element for it in 
conf/Catalina/[host]/[appName].xml, with a docBase attribute pointing to the 
actual location of the .war file (or directory).  You still do not use the path 
attribute; the URL path to the webapp is determined by the name of the .xml 
file.

 I am looking for a way to carry the context path information 
 inside the WAR itself due to my build process requirements.

You could easily have your deployment script change the name of the .war file 
when it's copied to the appBase directory.

 - 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: Running out of tomcat threads - why many threads in RUNNABLEstage even with no activity

 From: Pantvaidya, Vishwajit [mailto:vpant...@selectica.com]
 Subject: RE: Running out of tomcat threads - why many threads in
 RUNNABLEstage even with no activity

 From whatever I have read on this, it seems to me that this could 
 happen if a servlet writes something to a response stream, closes
 the response stream, but after that keeps on doing some processing
 (e.g. running an infinite loop).

No - the thread would be inside the servlet in that case.  The thread here in 
the RUNNABLE state is waiting for a *new* request to come in over an active AJP 
connection; a thread in the WAITING state would be assigned to a new connection 
when one is accepted.

 - 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

JNDI

2009-05-18 Thread daniel steel

hi all,
 i am pretty sure this has been hashed out many times but i could not get clear 
guidelines on how to accomplish JNDI Realm + tomcat 6 + windows AD.

I have got JNDI Realm + tomcat 6 + windows AD integration with basic 
authentication. as domain password is passed in clear text from browser to 
tomcat server, i would like to use digest http authentication. But digest auth 
is one way hash and tomcat is unable to authenticate the users against windows 
AD.

Windows AD doesn't give out password ( at least from  search) and so can't use 
comparitive mode in JNDI look up.

So how do send user password from browser to tomcat server hashed such a way 
that i could authenticate against windows AD?

One way i was thinking of MD5 the pass word on browser and tomcat authenticates 
with windows AD 
with MD5 scheme. So is there any setting that suggests to tomcat that do not 
Md5 the password but inform the LDAP provider the auth scheme is MD5.

thanks
d.

RE: Running out of tomcat threads - why many threads in RUNNABLEstage even with no activity

 -Original Message-
 From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
 Sent: Monday, May 18, 2009 4:02 PM
 To: Tomcat Users List
 Subject: RE: Running out of tomcat threads - why many threads in
 RUNNABLEstage even with no activity

  From: Pantvaidya, Vishwajit [mailto:vpant...@selectica.com]
  Subject: RE: Running out of tomcat threads - why many threads in
  RUNNABLEstage even with no activity

  From whatever I have read on this, it seems to me that this could
  happen if a servlet writes something to a response stream, closes
  the response stream, but after that keeps on doing some processing
  (e.g. running an infinite loop).

 No - the thread would be inside the servlet in that case.  The thread here
 in the RUNNABLE state is waiting for a *new* request to come in over an
 active AJP connection; a thread in the WAITING state would be assigned to
 a new connection when one is accepted.

[Pantvaidya, Vishwajit] 
Ok - so then the question is when does tomcat transition the thread from 
Running to Waiting?
Does that happen after AJP drops that connection?
So could the problem be occurring here because AJP is holding on to connections?

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

RE: Running out of tomcat threads - why many threads in RUNNABLEstage even with no activity

 From: Pantvaidya, Vishwajit [mailto:vpant...@selectica.com]
 Subject: RE: Running out of tomcat threads - why many threads in
 RUNNABLEstage even with no activity

 Ok - so then the question is when does tomcat transition 
 the thread from Running to Waiting? Does that happen after
 AJP drops that connection?

That's my understanding; I would presume some from of keep-alive is in play.  
However, others know the AJP characteristics better than I do.  Rainer is the 
ultimate resource, but I suspect he's asleep right now.

 So could the problem be occurring here because AJP is 
 holding on to connections?

Sorry, I haven't been following the thread that closely.  Not sure what the 
problem you're referring to actually is, but having a Tomcat thread reading 
input from the AJP connector is pretty normal.

 - 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: JNDI