> 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 re
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 Hibe
> 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, n
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
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
>
> Pe
-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 - http
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
-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 th
-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 joi
>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 t
> 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:
> maxThreads="150" minSpareThreads="1"/&
>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:
in Tomcat's server.xml. But I still see the problem when I cap my db
connection pool at 3.
I would think that I should be able to in
> 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
>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 b
> 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
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
>
> 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&
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
b
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 in
19 matches
Mail list logo
