Return-Path: 
 <users-return-212371-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org>
Delivered-To: apmail-tomcat-users-archive@www.apache.org
Received: (qmail 43934 invoked from network); 18 May 2010 12:46:34 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 18 May 2010 12:46:34 -0000
Received: (qmail 86898 invoked by uid 500); 18 May 2010 12:46:30 -0000
Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org
Received: (qmail 86699 invoked by uid 500); 18 May 2010 12:46:29 -0000
Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@tomcat.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@tomcat.apache.org>
List-Post: <mailto:users@tomcat.apache.org>
List-Id: <users.tomcat.apache.org>
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Delivered-To: mailing list users@tomcat.apache.org
Received: (qmail 86686 invoked by uid 99); 18 May 2010 12:46:29 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 May 2010 12:46:29 +0000
X-ASF-Spam-Status: No, hits=0.7 required=10.0
	tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received: from [76.96.62.56] (HELO qmta06.westchester.pa.mail.comcast.net)
 (76.96.62.56)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 May 2010 12:46:20 +0000
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43])
	by qmta06.westchester.pa.mail.comcast.net with comcast
	id JyMW1e0030vyq2s560m0M9; Tue, 18 May 2010 12:46:00 +0000
Received: from [192.168.1.202] ([69.143.124.247])
	by omta05.westchester.pa.mail.comcast.net with comcast
	id K0ly1e00N5LNqyD3R0lzDi; Tue, 18 May 2010 12:46:00 +0000
Message-ID: <4BF28C09.5060907@christopherschultz.net>
Date: Tue, 18 May 2010 08:46:01 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: MaxPermSize / Threads
References: <AANLkTimUFMx0dFnDRF0mBlB7yZ-TX2PvFzYvihFzB4q3@mail.gmail.com>
 	<4BF0FEFC.6030706@pidster.com>
 <AANLkTimvXAbvRuND11tYvYMKvxCd548Dew36ZRLqG-OE@mail.gmail.com>
 	<4BF10924.30303@pidster.com>
 <AANLkTiliZzDaZltzPQ0L4yzhJwCbSHPhhgsB3w-zu918@mail.gmail.com>
In-Reply-To: <AANLkTiliZzDaZltzPQ0L4yzhJwCbSHPhhgsB3w-zu918@mail.gmail.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked by ClamAV on apache.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ozgur,

On 5/17/2010 5:28 AM, Ozgur Ozdemircili wrote:
> I have the default server.conf file with :
> 
>  <Connector port="8080" protocol="HTTP/1.1"
>                maxThreads="250"
>                connectionTimeout="20000"
>                redirectPort="8443" />
> 
> I do not have any Executor.

<Executor>s are smart enough to close-down inactive request processor
threads after a certain amount of inactivity: regular <Connector>s are
too dumb: once a thread is created, it lives until the <Connector> is
shut down (usually only as the server is being stopped).

If you have 186 active request processor threads, that indicates that
the maximum load you experienced since the last TC startup was 186
simultaneous requests: congratulations! You probably have a
correctly-sized request processor pool for your webapp.

> Just wondering is it normal to have that much open threads waiting?

Not necessarily a problem, but if you were monitoring your webapp
closely, you might want those threads to expire so you could better
track the usage of your webapp during certain periods of time (like,
"nobody uses our app at 0300 but we get a lot of activity at 0500...
maybe we ought to move our backups from 0500 to 0300" or something like
that.

Since you're getting OOMEs, you might want to think about your webapp
and answer this question: what am I doing that can take-up a lot of
memory? XML processing using the DOM API is often a killer, as is any
kind of graphical image manipulation. Another culprit is storing too
much information in user sessions: if each session needs 100MiB and you
need to support 20 users, there's your 2GiB heap.

There are a lot of things that can take up a lot of memory when you
start getting a whole bunch of users together into memory.

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

iEYEARECAAYFAkvyjAkACgkQ9CaO5/Lv0PDEuACaA9pKP5bE8imCwHqyAVGjBAfi
vGwAnj+B/Fq47LvEoyQp9dRzspUYfnZZ
=RDuC
-----END PGP SIGNATURE-----

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