You're right, maybe I put this in the wrong forum. Below is a stack trace of
a request when it first enters my code on a successful request. In the error
case, my code is not being invoked.
I believe that all of the code below (except the top 4 call frames) are
coyote and catalina code. I thought
From: ped [mailto:[EMAIL PROTECTED]
Subject: RE: Tomcat thread pool question
I believe that all of the code below (except the top 4 call
frames) are coyote and catalina code.
It's the top frames that are critical, of course, since they show where the
thread is stuck.
When I recreate my
It's the top frames that are critical, of course, since they show where the
thread is stuck.
That stack trace is not from when the thread is hung - I put a bp on the
entry point to my code so that I could see what code an incoming request
must go thru before being passed to my code - my theory
From: ped [mailto:[EMAIL PROTECTED]
Subject: RE: Tomcat thread pool question
Perhaps there is a subtle bug here, or misconfiguration on
my part
It's not subtle - it's blatant. The db connection pool is exhausted, all of
the Tomcat threads are waiting for db connections to become available
all of the Tomcat threads are waiting for db connections to become available
So that implies that Tomcat only supports a max of 3 threads...
I uncommented:
Executor name=tomcatThreadPool namePrefix=catalina-exec-
maxThreads=150 minSpareThreads=1/
in Tomcat's server.xml. But I
From: ped [mailto:[EMAIL PROTECTED]
Subject: RE: Tomcat thread pool question
So that implies that Tomcat only supports a max of 3 threads...
Obviously untrue, since the default is 200.
I uncommented:
Executor name=tomcatThreadPool namePrefix=catalina-exec-
maxThreads=150
The Tomcat thread pool is finite; we'll call the maxThread value T.
Likewise, the db connection pool is finite, and we'll call its size D. The
client makes some number of requests that are not committed, which we'll
label R. Anytime R T + D, you're stuck.
Yes - that's my understanding of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ped,
ped wrote:
If I execute the loop N-1 times, I have no problems - I can execute my loop
over and over. I can verify that I am not leaking connections (I have a
monitor thread that displays the number of active connections).
I'm probably
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ped,
ped wrote:
I would think that I should be able to increase the number of threads
available to Tomcat to prevent this problem (I'm not saying that is the
correct solution to my problem - I fully understand that our design is the
root of this
ped schrieb am 10.12.2008 um 10:33:23 (-0800):
The Tomcat thread pool is finite; we'll call the maxThread value T.
Likewise, the db connection pool is finite, and we'll call its size
D. The client makes some number of requests that are not committed,
which we'll label R. Anytime R T +
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
Christopher Schultz wrote:
So, unless you have maxActive == dbcp size, you're screwed.
Er, that should be maxActive == maxThreads.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -
does
not necessarily endorse content contained within this transmission.
Date: Wed, 10 Dec 2008 17:15:39 -0500
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Subject: Re: Tomcat thread pool question
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ped,
ped wrote:
If I execute
Possibly [OT], and just disregard if so.
I am just trying to follow this thread and to understand, from my very
superficial and elementary knowledge of things Java and Tomcat.
So we have a Tomcat, which somehow has a pool of database connections
ready to be lent to webapps.
And we have a
From: André Warnier [mailto:[EMAIL PROTECTED]
Subject: Re: Tomcat thread pool question
So we have a Tomcat, which somehow has a pool of database
connections ready to be lent to webapps.
In this particular case, the db connection pool is managed by Hibernate, not
Tomcat. More typical usage
Caldarale, Charles R wrote:
From: André Warnier [mailto:[EMAIL PROTECTED]
Subject: Re: Tomcat thread pool question
So we have a Tomcat, which somehow has a pool of database
connections ready to be lent to webapps.
In this particular case, the db connection pool is managed by Hibernate
From: André Warnier [mailto:[EMAIL PROTECTED]
Subject: Re: Tomcat thread pool question
So it has nothing to do directly with the threads.
Only in determining how many requests can be accepted by Tomcat before going on
the limited TCP/IP queue and subsequent requests being rejected.
I
Hi Peter,
ped wrote:
The problem occurs if I set max threads to N and execute the above loop N+1
or more times (where N is a small number like 3 or 4). I see Tomcat threads
sitting in c3p0 code waiting for a connection. There is no thread handling
the incoming commit calls (step 3 above). The
Tomcat does not return any error - any requests after I have exhausted the
pool,, are sitting in a wait state waiting for a DB connection to be freed.
No DB connections will be freed because the requests from the client that
are trying to perform commits (thereby freeing a DB connection) are not
From: ped [mailto:[EMAIL PROTECTED]
Subject: Re: Tomcat thread pool question
No DB connections will be freed because the requests from the
client that are trying to perform commits (thereby freeing a DB
connection) are not being processed by Tomcat.
Tomcat doesn't process requests - your
19 matches
Mail list logo
