You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by André Vila Cova <an...@gmail.com> on 2007/07/11 19:01:17 UTC
Tomcat - All threads (200) are currently busy
Hello!
I get lot of times the following error:
SEVERE: All threads (200) are currently *busy*, waiting. *Increase
maxThreads*
**
*Strange is that i've configured in server.xml the following
(maxThreads=400):*
*
<Connector
port="8085" maxHttpHeaderSize="8192"
maxThreads="400" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="5000" disableUploadTimeout="true" />
*
*Yes, I already restarted tomcat...*
**
*First: Why I get the previous error?*
*Second: Why in error I see 200?*
**
Release............ : Jakarta-Tomcat 5.5.20
The architecture is based on a web server on a server and tomcat in other
server... When I execute ping i get :
64 bytes from 192.168.30.11: icmp_seq=11953 ttl=63 time=0.648 ms
64 bytes from 192.168.30.11: icmp_seq=11954 ttl=63 time=0.654 ms
64 bytes from 192.168.30.11: icmp_seq=11955 ttl=63 time=0.664 ms
64 bytes from 192.168.30.11: icmp_seq=11956 ttl=63 time=0.657 ms
64 bytes from 192.168.30.11: icmp_seq=11957 ttl=63 time=0.656 ms
64 bytes from 192.168.30.11: icmp_seq=11958 ttl=63 time=0.654 ms
64 bytes from 192.168.30.11: icmp_seq=11959 ttl=63 time=0.664 ms
64 bytes from 192.168.30.11: icmp_seq=11960 ttl=63 time=0.674 ms
64 bytes from 192.168.30.11: icmp_seq=11961 ttl=63 time=0.659 ms
Could you help me please?
Regards
Thank You
Re: Tomcat - All threads (200) are currently busy
Posted by Leon Rosenberg <ro...@googlemail.com>.
cause your threads are all busy serving requests (or hanging
somewhere). Perform a thread dump with kill -QUIT and you'll see what
they are doing.
regards
Leon
On 7/11/07, André Vila Cova <an...@gmail.com> wrote:
> I don't think so... I will see..but, why i get the error?
> SEVERE: All threads (200) are currently *busy*, waiting. *Increase
>
>
> On 7/11/07, Mladen Turk <ml...@gmail.com> wrote:
> >
> > André Vila Cova wrote:
> > > Hello!
> > >
> > > I get lot of times the following error:
> > >
> > > SEVERE: All threads (200) are currently *busy*, waiting. *Increase
> > > maxThreads*
> > > **
> > > *Strange is that i've configured in server.xml the following
> > > (maxThreads=400):*
> > > *
> > >
> >
> > You have probably done that for a wrong connector.
> >
> > Regards,
> > Mladen.
> >
> > ---------------------------------------------------------------------
> > To start a new topic, e-mail: users@tomcat.apache.org
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat - All threads (200) are currently busy
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Ingo Krabbe [mailto:ikrabbe.ask@web.de]
> Subject: Re: Tomcat - All threads (200) are currently busy
>
> > "http-8085-Processor24" daemon prio=1 tid=0x082f1378 nid=0x19c6 in
> > Object.wait() [0xde118000..0xde118e20]
> > at java.lang.Object.wait(Native Method)
> > - waiting on <0xe619f748> (a
> > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
> > at java.lang.Object.wait(Object.java:474)
> > at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
> > ThreadPool.java:656)
> > - locked <0xe619f748> (a
> > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
> > at java.lang.Thread.run(Thread.java:595)
> >
>
> somehow this looks like a deadlock.
Why do you say that? Looks like a normal wait() for an idle connector thread to me.
- 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat - All threads (200) are currently busy
Posted by André Vila Cova <an...@gmail.com>.
1 . no
2 . lot of users
On 7/12/07, Leon Rosenberg <ro...@googlemail.com> wrote:
>
> Stupid question:
> 1. are you using keep alive?
> 2. how many users are actually on?
> regards
> Leon
>
> On 7/13/07, Christopher Schultz <ch...@christopherschultz.net> wrote:
> > Ingo,
> >
> > Ingo Krabbe wrote:
> > > Am Donnerstag, 12. Juli 2007 19:12 schrieb André Vila Cova:
> > >> "http-8085-Processor24" daemon prio=1 tid=0x082f1378 nid=0x19c6 in
> > >> Object.wait() [0xde118000..0xde118e20]
> > >> at java.lang.Object.wait(Native Method)
> > >> - waiting on <0xe619f748> (a
> > >> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
> > >
> > > somehow this looks like a deadlock.
> >
> > I agree with Chuck: this is just an Object.wait() being called on the
> > ControlRunnable object (which is probably the monitor for the thread
> > pool). Most threads will be in this state. If you have threads in this
> > state, then they are /not/ busy... they're waiting around for something
> > to do!
> >
> > -chris
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat - All threads (200) are currently busy
Posted by Leon Rosenberg <ro...@googlemail.com>.
Stupid question:
1. are you using keep alive?
2. how many users are actually on?
regards
Leon
On 7/13/07, Christopher Schultz <ch...@christopherschultz.net> wrote:
> Ingo,
>
> Ingo Krabbe wrote:
> > Am Donnerstag, 12. Juli 2007 19:12 schrieb André Vila Cova:
> >> "http-8085-Processor24" daemon prio=1 tid=0x082f1378 nid=0x19c6 in
> >> Object.wait() [0xde118000..0xde118e20]
> >> at java.lang.Object.wait(Native Method)
> >> - waiting on <0xe619f748> (a
> >> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
> >
> > somehow this looks like a deadlock.
>
> I agree with Chuck: this is just an Object.wait() being called on the
> ControlRunnable object (which is probably the monitor for the thread
> pool). Most threads will be in this state. If you have threads in this
> state, then they are /not/ busy... they're waiting around for something
> to do!
>
> -chris
>
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat - All threads (200) are currently busy
Posted by Christopher Schultz <ch...@christopherschultz.net>.
André,
André Vila Cova wrote:
> And it's possible to know what threads are really doing?
> And I don't understand why having the following 3 connectors
>
> maxThreads="400" minSpareThreads="25" maxSpareThreads="75"
> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
> maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
>
> I get error:
> SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads
> (200) or check the servlet status.
> Why 200? I dont have configured the value 200.
Something is not right. It's possible that the "(200)" is a programming
oversight and it's not giving you the right number of threads, but that
is unlikely.
What is more likely is that you are misreading your own configuration
file, or Tomcat is using a different configuration file than you think
it is.
-chris
Re: Tomcat - All threads (200) are currently busy
Posted by André Vila Cova <an...@gmail.com>.
And it's possible to know what threads are really doing?
And I don't understand why having the following 3 connectors
maxThreads="400" minSpareThreads="25" maxSpareThreads="75"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
I get error:
SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads
(200) or check the servlet status.
Why 200? I dont have configured the value 200.
Thank you
On 7/12/07, Christopher Schultz <ch...@christopherschultz.net> wrote:
>
> Ingo,
>
> Ingo Krabbe wrote:
> > Am Donnerstag, 12. Juli 2007 19:12 schrieb André Vila Cova:
> >> "http-8085-Processor24" daemon prio=1 tid=0x082f1378 nid=0x19c6 in
> >> Object.wait() [0xde118000..0xde118e20]
> >> at java.lang.Object.wait(Native Method)
> >> - waiting on <0xe619f748> (a
> >> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
> >
> > somehow this looks like a deadlock.
>
> I agree with Chuck: this is just an Object.wait() being called on the
> ControlRunnable object (which is probably the monitor for the thread
> pool). Most threads will be in this state. If you have threads in this
> state, then they are /not/ busy... they're waiting around for something
> to do!
>
> -chris
>
>
>
>
Re: Tomcat - All threads (200) are currently busy
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Ingo,
Ingo Krabbe wrote:
> Am Donnerstag, 12. Juli 2007 19:12 schrieb André Vila Cova:
>> "http-8085-Processor24" daemon prio=1 tid=0x082f1378 nid=0x19c6 in
>> Object.wait() [0xde118000..0xde118e20]
>> at java.lang.Object.wait(Native Method)
>> - waiting on <0xe619f748> (a
>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
>
> somehow this looks like a deadlock.
I agree with Chuck: this is just an Object.wait() being called on the
ControlRunnable object (which is probably the monitor for the thread
pool). Most threads will be in this state. If you have threads in this
state, then they are /not/ busy... they're waiting around for something
to do!
-chris
Re: Tomcat - All threads (200) are currently busy
Posted by Ingo Krabbe <ik...@web.de>.
Am Donnerstag, 12. Juli 2007 19:12 schrieb André Vila Cova:
> Lot of waits... Could you help me?
>
> "http-8085-Processor24" daemon prio=1 tid=0x082f1378 nid=0x19c6 in
> Object.wait() [0xde118000..0xde118e20]
> at java.lang.Object.wait(Native Method)
> - waiting on <0xe619f748> (a
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
> at java.lang.Object.wait(Object.java:474)
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
> ThreadPool.java:656)
> - locked <0xe619f748> (a
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
> at java.lang.Thread.run(Thread.java:595)
>
somehow this looks like a deadlock.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat - All threads (200) are currently busy
Posted by André Vila Cova <an...@gmail.com>.
Lot of waits... Could you help me?
"http-8085-Processor24" daemon prio=1 tid=0x082f1378 nid=0x19c6 in
Object.wait() [0xde118000..0xde118e20]
at java.lang.Object.wait(Native Method)
- waiting on <0xe619f748> (a
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Object.wait(Object.java:474)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:656)
- locked <0xe619f748> (a
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Thread.run(Thread.java:595)
"http-8085-Processor23" daemon prio=1 tid=0x082f0470 nid=0x19c5 in
Object.wait() [0xde199000..0xde199da0]
at java.lang.Object.wait(Native Method)
- waiting on <0xe61c2360> (a
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Object.wait(Object.java:474)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:656)
- locked <0xe61c2360> (a
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Thread.run(Thread.java:595)
"http-8085-Processor22" daemon prio=1 tid=0x084561c8 nid=0x19c4 in
Object.wait() [0xde21a000..0xde21b120]
at java.lang.Object.wait(Native Method)
- waiting on <0xe61c21e8> (a
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Object.wait(Object.java:474)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:656)
- locked <0xe61c21e8> (a
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
at java.lang.Thread.run(Thread.java:595)
On 7/12/07, André Vila Cova <an...@gmail.com> wrote:
>
> More information on catalina.out:
>
> "TP-Processor80" daemon prio=1 tid=0xe0370988 nid=0x1c19 runnable
> [0xda178000..0xda178fa0]
> 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)
> - locked <0xf0caa5d0> (a java.io.BufferedInputStream)
> at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:620)
> at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:558)
> at org.apache.jk.common.ChannelSocket.processConnection(
> ChannelSocket.java:685)
> at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(
> ChannelSocket.java:889)
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (
> ThreadPool.java:684)
> at java.lang.Thread.run(Thread.java:595)
>
> "TP-Processor79" daemon prio=1 tid=0xe036ffd8 nid=0x1c18 runnable
> [0xda1f9000..0xda1f9f20]
> 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)
> - locked <0xf0ca5d20> (a java.io.BufferedInputStream)
> at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:620)
> at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:558)
> at org.apache.jk.common.ChannelSocket.processConnection(
> ChannelSocket.java:685)
> at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(
> ChannelSocket.java:889)
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (
> ThreadPool.java:684)
> at java.lang.Thread.run(Thread.java:595)
>
> "TP-Processor78" daemon prio=1 tid=0xe036f678 nid=0x1c17 runnable
> [0xda27a000..0xda27aea0]
> 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)
> - locked <0xeff48930> (a java.io.BufferedInputStream)
> at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:620)
> at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:558)
> at org.apache.jk.common.ChannelSocket.processConnection(
> ChannelSocket.java:685)
> at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(
> ChannelSocket.java:889)
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (
> ThreadPool.java:684)
> at java.lang.Thread.run(Thread.java:595)
>
> "TP-Processor77" daemon prio=1 tid=0xe036f0a0 nid=0x1c16 runnable
> [0xda2fb000..0xda2fbe20]
> 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)
> - locked <0xeff48ff8> (a java.io.BufferedInputStream)
> at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:620)
> at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:558)
> at org.apache.jk.common.ChannelSocket.processConnection(
> ChannelSocket.java:685)
> at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(
> ChannelSocket.java:889)
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (
> ThreadPool.java:684)
> at java.lang.Thread.run(Thread.java:595)
> ...
>
> Thank you
>
>
> On 7/12/07, André Vila Cova <an...@gmail.com> wrote:
> >
> > I get following output after executing Kill -quit 6555... I don't know
> > what information I need to analyze. Could you help me?
> >
> > [root@alertapp01 hsperfdata_tomcat]# strings 6555
> > sun.rt.createVmBeginTime
> > sun.rt.createVmEndTime
> > sun.rt.vmInitDoneTime
> > java.threads.started
> > java.threads.live
> > java.threads.livePeak
> > java.threads.daemon
> > sun.rt.safepointSyncTime
> > sun.rt.safepoints
> > sun.rt.safepointTime
> > sun.rt.applicationTime
> > java.cls.loadedClasses
> > java.cls.unloadedClasses
> > java.cls.sharedLoadedClasses
> > java.cls.sharedUnloadedClasses
> > sun.cls.loadedBytes
> > sun.cls.unloadedBytes
> > sun.cls.sharedLoadedBytes
> > sun.cls.sharedUnloadedBytes
> > sun.cls.methodBytes
> > sun.cls.time
> > sun.cls.initializedClasses
> > sun.cls.classInitTime
> > sun.cls.classVerifyTime
> > sun.gc.cause
> > No GC
> > sun.gc.lastCause
> > unknown GCCause
> > sun.gc.generation.0.name
> > sun.gc.generation.0.spaces
> > sun.gc.generation.0.minCapacity
> > sun.gc.generation.0.maxCapacity
> > sun.gc.generation.0.capacity
> > sun.gc.generation.0.space.0.name
> > eden
> > sun.gc.generation.0.space.0.maxCapacity
> > sun.gc.generation.0.space.0.capacity
> > sun.gc.generation.0.space.0.used
> > sun.gc.generation.0.space.0.initCapacity
> > sun.gc.generation.0.space.1.name
> > sun.gc.generation.0.space.1.maxCapacity
> > sun.gc.generation.0.space.1.capacity
> > sun.gc.generation.0.space.1.used
> > sun.gc.generation.0.space.1.initCapacity
> > sun.gc.generation.0.space.2.name
> > sun.gc.generation.0.space.2.maxCapacity
> > sun.gc.generation.0.space.2.capacity
> > sun.gc.generation.0.space.2.used
> > sun.gc.generation.0.space.2.initCapacity
> > sun.gc.generation.1.name
> > sun.gc.generation.1.spaces
> > sun.gc.generation.1.minCapacity
> > sun.gc.generation.1.maxCapacity
> > sun.gc.generation.1.capacity
> > sun.gc.generation.1.space.0.name
> > sun.gc.generation.1.space.0.maxCapacity
> > sun.gc.generation.1.space.0.capacity
> > sun.gc.generation.1.space.0.used
> > sun.gc.generation.1.space.0.initCapacity
> > sun.gc.generation.2.name
> > perm
> > sun.gc.generation.2.spaces
> > sun.gc.generation.2.minCapacity
> > sun.gc.generation.2.maxCapacity
> > sun.gc.generation.2.capacity
> > sun.gc.generation.2.space.0.name
> > perm
> > sun.gc.generation.2.space.0.maxCapacity
> > sun.gc.generation.2.space.0.capacity
> > sun.gc.generation.2.space.0.used
> > sun.gc.generation.2.space.0.initCapacity
> > sun.gc.policy.name
> > ParScav:MSC
> > sun.gc.policy.collectors
> > sun.gc.policy.generations
> > sun.gc.policy.maxTenuringThreshold
> > sun.gc.policy.tenuringThreshold
> > sun.gc.policy.desiredSurvivorSize
> > sun.gc.policy.edenSize
> > sun.gc.policy.promoSize
> > sun.gc.policy.oldPromoSize
> > sun.gc.policy.oldEdenSize
> > sun.gc.policy.oldCapacity
> > sun.gc.policy.youngCapacity
> > sun.gc.policy.boundaryMoved
> > sun.gc.policy.avgSurvivedAvg
> > sun.gc.policy.avgSurvivedDev
> > sun.gc.policy.avgSurvivedPaddedAvg
> > sun.gc.policy.avgPromotedAvg
> > sun.gc.policy.avgPromotedDev
> > sun.gc.policy.avgPromotedPaddedAvg
> > sun.gc.policy.avgPretenuredPaddedAvg
> > sun.gc.policy.survived
> > sun.gc.policy.promoted
> > sun.gc.policy.survivorOverflowed
> > sun.gc.policy.decrementTenuringThresholdForGcCost
> > sun.gc.policy.incrementTenuringThresholdForGcCost
> > sun.gc.policy.decrementTenuringThresholdForSurvivorLimit
> > sun.gc.policy.changeOldGenForMajPauses
> > sun.gc.policy.changeYoungGenForMinPauses
> > sun.gc.policy.changeYoungGenForMajPauses
> > sun.gc.policy.changeOldGenForMinPauses
> > sun.gc.policy.increaseOldGenForThroughput
> > sun.gc.policy.increaseYoungGenForThroughput
> > sun.gc.policy.decreaseForFootprint
> > sun.gc.policy.decideAtFullGc
> > sun.gc.policy.avgMinorPauseTime
> > sun.gc.policy.avgMajorPauseTime
> > sun.gc.policy.avgMinorIntervalTime
> > sun.gc.policy.avgMajorIntervalTime
> > sun.gc.policy.minorGcCost
> > sun.gc.policy.majorGcCost
> > sun.gc.policy.mutatorCost
> > sun.gc.policy.liveSpace
> > sun.gc.policy.freeSpace
> > sun.gc.policy.avgBaseFootprint
> > sun.gc.policy.avgYoungLive
> > sun.gc.policy.avgOldLive
> > sun.gc.policy.gcTimeLimitExceeded
> > sun.gc.policy.liveAtLastFullGc
> > sun.gc.policy.majorPauseOldSlope
> > sun.gc.policy.minorPauseOldSlope
> > sun.gc.policy.majorPauseYoungSlope
> > sun.gc.policy.minorPauseYoungSlope
> > sun.gc.policy.majorCollectionSlope
> > sun.gc.policy.minorCollectionSlope
> > sun.gc.policy.scavengeSkipped
> > sun.gc.policy.fullFollowsScavenge
> > sun.gc.tlab.allocThreads
> > sun.gc.tlab.fills
> > sun.gc.tlab.maxFills
> > sun.gc.tlab.alloc
> > sun.gc.tlab.gcWaste
> > sun.gc.tlab.maxGcWaste
> > sun.gc.tlab.slowWaste
> > sun.gc.tlab.maxSlowWaste
> > sun.gc.tlab.fastWaste
> > sun.gc.tlab.maxFastWaste
> > sun.gc.tlab.slowAlloc
> > sun.gc.tlab.maxSlowAlloc
> > sun.gc.collector.0.name
> > PSScavenge
> > sun.gc.collector.0.invocations
> > sun.gc.collector.0.time
> > sun.gc.collector.0.lastEntryTime
> > sun.gc.collector.0.lastExitTime
> > sun.gc.collector.1.name
> > PSMarkSweep
> > sun.gc.collector.1.invocations
> > sun.gc.collector.1.time
> > sun.gc.collector.1.lastEntryTime
> > sun.gc.collector.1.lastExitTime
> > sun.threads.vmOperationTime
> > sun.ci.adapterThread.method
> > sun.ci.adapterThread.type
> > sun.ci.adapterThread.time
> > sun.ci.adapterThread.compiles
> > sun.ci.compilerThread.0.method
> > sun.ci.compilerThread.0.type
> > sun.ci.compilerThread.0.time
> > sun.ci.compilerThread.0.compiles
> > sun.ci.compilerThread.1.method
> > sun.ci.compilerThread.1.type
> > sun.ci.compilerThread.1.time
> > sun.ci.compilerThread.1.compiles
> > sun.ci.threads
> > java.ci.totalTime
> > sun.ci.nativeTime
> > sun.ci.osrTime
> > sun.ci.standardTime
> > sun.ci.totalBailouts
> > sun.ci.totalInvalidates
> > sun.ci.totalCompiles
> > sun.ci.nativeCompiles
> > sun.ci.osrCompiles
> > sun.ci.standardCompiles
> > sun.ci.osrBytes
> > sun.ci.standardBytes
> > sun.ci.nmethodSize
> > sun.ci.nmethodCodeSize
> > sun.ci.lastMethod
> > org/hibernate/persister/entity/AbstractEntityPersister hasProxy
> > sun.ci.lastFailedMethod
> > sun.ci.lastInvalidatedMethod
> > sun.ci.lastType
> > sun.ci.lastSize
> > sun.ci.lastFailedType
> > sun.ci.lastInvalidatedType
> > sun.os.hrt.frequency
> > java.property.java.vm.specification.version
> > java.property.java.vm.specification.name
> > Java Virtual Machine Specification
> > java.property.java.vm.specification.vendor
> > Sun Microsystems Inc.
> > java.property.java.vm.version
> > 1.5.0_11-b03
> > java.property.java.vm.name
> > Java HotSpot(TM) Server VM
> > java.property.java.vm.vendor
> > Sun Microsystems Inc.
> > java.property.java.vm.info
> > mixed mode
> > java.property.java.library.path
> > /usr/local/jdk1.5.0_11/jre/lib/i386/server:/usr/local/jdk1.5.0_11/jre/lib/i386:/usr/local/jdk1.5.0_11/jre/../lib/i386:/usr/local/tomcat5/bin
> >
> > java.property.java.class.path
> > :/usr/local/tomcat5/bin/bootstrap.jar:/usr/local/tomcat5/bin/commons-
> > logging-api.jar
> > java.property.java.endorsed.dirs
> > /usr/local/tomcat5/common/endorsed
> > java.property.java.ext.dirs
> > /usr/local/jdk1.5.0_11/jre/lib/ext
> > java.property.java.home
> > /usr/local/jdk1.5.0_11/jre
> > sun.property.sun.boot.class.path
> > /usr/local/tomcat5/common/endorsed/rowset.jar:/usr/local/jdk1.5.0_11/jre/lib/rt.jar:/usr/local/jdk1.5.0_11/jre/lib/i18n.jar:/usr/local/jdk1.5.0_11/jre/lib/sunrsasign.jar:/usr/local/jdk1.5.0_11/jre/lib/jsse.jar:/usr/local/jdk1.5.0_11/jre/lib/jce.jar:/usr/local/jdk1.5.0_11/jre/lib/charsets.jar:/usr/local/jdk1.5.0_11/jre/classes
> >
> > sun.property.sun.boot.library.path
> > /usr/local/jdk1.5.0_11/jre/lib/i386
> > java.rt.vmFlags
> > java.rt.vmArgs
> > -Xms64m -Xmx200m -Xss512k -
> > Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -
> > Djava.util.logging.config.file=/alert/training/tomcatvw/conf/logging.properties-
> > Dorg.xml.sax.driver=org.apache.xerces.parsers.SAXParser -
> > Doracle.jdbc.V8Compatible=true -
> > Doracledatabasemetadata.get_lob_precision=false -
> > Djava.endorsed.dirs=/usr/local/tomcat5/common/endorsed -
> > Dcatalina.base=/alert/training/tomcatvw -
> > Dcatalina.home=/usr/local/tomcat5 -
> > Djava.io.tmpdir=/alert/training/tomcatvw/temp
> > sun.rt.javaCommand
> > org.apache.catalina.startup.Bootstrap start
> > sun.rt.internalVersion
> > Java HotSpot(TM) Server VM (1.5.0_11-b03 ) for linux-x86, built on Dec
> > 15 2006 01:12:32 by java_re with gcc 3.2.1-7a (J2SE release)
> > sun.os.hrt.ticks
> >
> >
> >
> > On 7/12/07, Ingo Krabbe <ikrabbe.ask@web.de > wrote:
> > >
> > >
> > > We happend to have similar problems when starting with tomcat. Our
> > > main error
> > > was a failing connection to the database, while the connector had it's
> > > retry
> > > flag on. So the answer to each request was, trying to connect to a
> > > unconnectable database until the timeout has been reached, which is
> > > too long
> > > for any busy site of course.
> > >
> > > Before you examine all your threads you should test your application
> > > for such
> > > errors that delay the answer to requests.
> > >
> > > Maybe you should also try to build a test setup, answering very simple
> > > to your
> > > requests (hello, world) and push in one application module each time
> > > to see
> > > at which state your application breaks.
> > >
> > > When you get this error very fast the error should occure at one quite
> > > central
> > > point in your code.
> > >
> > > Also consult access and error logs of the tomcat process (catalina.outand
> > > similar).
> > >
> > > Writing your own log files by your jsp pages is also quite helpfull
> > > sometimes.
> > >
> > > Am Donnerstag, 12. Juli 2007 15:02 schrieb André Vila Cova:
> > > > Hi!
> > > >
> > > > I've this two processes:
> > > >
> > > > tomcat 6404 0.0 2.6 484396 105456 ? Sl 01:05 0:14
> > > > /usr/local/java1.5/bin/java -Xms64m -Xmx200m -Xss512k -
> > > > Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -
> > > > Djava.util.logging.conf
> > > > tomcat 6555 0.1 3.8 516420 154452 ? Sl 01:09 0:39
> > > > /usr/local/java1.5/bin/java -Xms64m -Xmx200m -Xss512k -
> > > > Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -
> > > > Djava.util.logging.conf
> > > >
> > > > Output is null when I execute the following command:
> > > > [root@alertapp01 ~]# kill -QUIT 6404
> > > > [root@alertapp01 ~]#
> > > >
> > > > How can I see what thread is doing?
> > > >
> > > > Thank You
> > > >
> > > > On 7/11/07, Titi Wangsa < blacksnow666@gmail.com> wrote:
> > > > > probably some threads are performing database operation
> > > > > and it takes too long so new threads are being spawned,
> > > > > the new threads are also taking too long, so newer threads are
> > > being
> > > > > spawned.
> > > > > too much spawning, that is what is causing the limit break.
> > > > >
> > > > > On 7/12/07, André Vila Cova < andremailinglist@gmail.com > wrote:
> > > > > > I don't think so... I will see..but, why i get the error?
> > > > > > SEVERE: All threads (200) are currently *busy*, waiting.
> > > *Increase
> > > > > >
> > > > > > On 7/11/07, Mladen Turk < mladen.turk@gmail.com> wrote:
> > > > > > > André Vila Cova wrote:
> > > > > > > > Hello!
> > > > > > > >
> > > > > > > > I get lot of times the following error:
> > > > > > > >
> > > > > > > > SEVERE: All threads (200) are currently *busy*, waiting.
> > > *Increase
> > > > > > > > maxThreads*
> > > > > > > > **
> > > > > > > > *Strange is that i've configured in server.xml the following
> > > > > > > > (maxThreads=400):*
> > > > > > > > *
> > > > > > >
> > > > > > > You have probably done that for a wrong connector.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Mladen.
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To start a new topic, e-mail: users@tomcat.apache.org
> > > > > > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > > > > > For additional commands, e-mail: users-help@tomcat.apache.org
> > >
> > > --
> > > ==================================================
> > > Ingo Krabbe ASK UNIX Systems
> > > Burggrafenstraße 3
> > > 44139 Dortmund
> > >
> > > Telefon 0231 4770185
> > > FAX 0231 4770186
> > > E-Mail ikrabbe.ask@web.de
> > > Fingerprint EE5A 6533 EE5E 8F66 EC20 C56A 35FC
> > > B736 18FD EB5A
> > > ==================================================
> > >
> >
> >
>
Re: Tomcat - All threads (200) are currently busy
Posted by André Vila Cova <an...@gmail.com>.
More information on catalina.out:
"TP-Processor80" daemon prio=1 tid=0xe0370988 nid=0x1c19 runnable
[0xda178000..0xda178fa0]
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)
- locked <0xf0caa5d0> (a java.io.BufferedInputStream)
at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:620)
at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java
:558)
at org.apache.jk.common.ChannelSocket.processConnection(
ChannelSocket.java:685)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(
ChannelSocket.java:889)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
"TP-Processor79" daemon prio=1 tid=0xe036ffd8 nid=0x1c18 runnable
[0xda1f9000..0xda1f9f20]
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)
- locked <0xf0ca5d20> (a java.io.BufferedInputStream)
at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:620)
at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java
:558)
at org.apache.jk.common.ChannelSocket.processConnection(
ChannelSocket.java:685)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(
ChannelSocket.java:889)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
"TP-Processor78" daemon prio=1 tid=0xe036f678 nid=0x1c17 runnable
[0xda27a000..0xda27aea0]
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)
- locked <0xeff48930> (a java.io.BufferedInputStream)
at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:620)
at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java
:558)
at org.apache.jk.common.ChannelSocket.processConnection(
ChannelSocket.java:685)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(
ChannelSocket.java:889)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
"TP-Processor77" daemon prio=1 tid=0xe036f0a0 nid=0x1c16 runnable
[0xda2fb000..0xda2fbe20]
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)
- locked <0xeff48ff8> (a java.io.BufferedInputStream)
at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:620)
at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java
:558)
at org.apache.jk.common.ChannelSocket.processConnection(
ChannelSocket.java:685)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(
ChannelSocket.java:889)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
...
Thank you
On 7/12/07, André Vila Cova <an...@gmail.com> wrote:
>
> I get following output after executing Kill -quit 6555... I don't know
> what information I need to analyze. Could you help me?
>
> [root@alertapp01 hsperfdata_tomcat]# strings 6555
> sun.rt.createVmBeginTime
> sun.rt.createVmEndTime
> sun.rt.vmInitDoneTime
> java.threads.started
> java.threads.live
> java.threads.livePeak
> java.threads.daemon
> sun.rt.safepointSyncTime
> sun.rt.safepoints
> sun.rt.safepointTime
> sun.rt.applicationTime
> java.cls.loadedClasses
> java.cls.unloadedClasses
> java.cls.sharedLoadedClasses
> java.cls.sharedUnloadedClasses
> sun.cls.loadedBytes
> sun.cls.unloadedBytes
> sun.cls.sharedLoadedBytes
> sun.cls.sharedUnloadedBytes
> sun.cls.methodBytes
> sun.cls.time
> sun.cls.initializedClasses
> sun.cls.classInitTime
> sun.cls.classVerifyTime
> sun.gc.cause
> No GC
> sun.gc.lastCause
> unknown GCCause
> sun.gc.generation.0.name
> sun.gc.generation.0.spaces
> sun.gc.generation.0.minCapacity
> sun.gc.generation.0.maxCapacity
> sun.gc.generation.0.capacity
> sun.gc.generation.0.space.0.name
> eden
> sun.gc.generation.0.space.0.maxCapacity
> sun.gc.generation.0.space.0.capacity
> sun.gc.generation.0.space.0.used
> sun.gc.generation.0.space.0.initCapacity
> sun.gc.generation.0.space.1.name
> sun.gc.generation.0.space.1.maxCapacity
> sun.gc.generation.0.space.1.capacity
> sun.gc.generation.0.space.1.used
> sun.gc.generation.0.space.1.initCapacity
> sun.gc.generation.0.space.2.name
> sun.gc.generation.0.space.2.maxCapacity
> sun.gc.generation.0.space.2.capacity
> sun.gc.generation.0.space.2.used
> sun.gc.generation.0.space.2.initCapacity
> sun.gc.generation.1.name
> sun.gc.generation.1.spaces
> sun.gc.generation.1.minCapacity
> sun.gc.generation.1.maxCapacity
> sun.gc.generation.1.capacity
> sun.gc.generation.1.space.0.name
> sun.gc.generation.1.space.0.maxCapacity
> sun.gc.generation.1.space.0.capacity
> sun.gc.generation.1.space.0.used
> sun.gc.generation.1.space.0.initCapacity
> sun.gc.generation.2.name
> perm
> sun.gc.generation.2.spaces
> sun.gc.generation.2.minCapacity
> sun.gc.generation.2.maxCapacity
> sun.gc.generation.2.capacity
> sun.gc.generation.2.space.0.name
> perm
> sun.gc.generation.2.space.0.maxCapacity
> sun.gc.generation.2.space.0.capacity
> sun.gc.generation.2.space.0.used
> sun.gc.generation.2.space.0.initCapacity
> sun.gc.policy.name
> ParScav:MSC
> sun.gc.policy.collectors
> sun.gc.policy.generations
> sun.gc.policy.maxTenuringThreshold
> sun.gc.policy.tenuringThreshold
> sun.gc.policy.desiredSurvivorSize
> sun.gc.policy.edenSize
> sun.gc.policy.promoSize
> sun.gc.policy.oldPromoSize
> sun.gc.policy.oldEdenSize
> sun.gc.policy.oldCapacity
> sun.gc.policy.youngCapacity
> sun.gc.policy.boundaryMoved
> sun.gc.policy.avgSurvivedAvg
> sun.gc.policy.avgSurvivedDev
> sun.gc.policy.avgSurvivedPaddedAvg
> sun.gc.policy.avgPromotedAvg
> sun.gc.policy.avgPromotedDev
> sun.gc.policy.avgPromotedPaddedAvg
> sun.gc.policy.avgPretenuredPaddedAvg
> sun.gc.policy.survived
> sun.gc.policy.promoted
> sun.gc.policy.survivorOverflowed
> sun.gc.policy.decrementTenuringThresholdForGcCost
> sun.gc.policy.incrementTenuringThresholdForGcCost
> sun.gc.policy.decrementTenuringThresholdForSurvivorLimit
> sun.gc.policy.changeOldGenForMajPauses
> sun.gc.policy.changeYoungGenForMinPauses
> sun.gc.policy.changeYoungGenForMajPauses
> sun.gc.policy.changeOldGenForMinPauses
> sun.gc.policy.increaseOldGenForThroughput
> sun.gc.policy.increaseYoungGenForThroughput
> sun.gc.policy.decreaseForFootprint
> sun.gc.policy.decideAtFullGc
> sun.gc.policy.avgMinorPauseTime
> sun.gc.policy.avgMajorPauseTime
> sun.gc.policy.avgMinorIntervalTime
> sun.gc.policy.avgMajorIntervalTime
> sun.gc.policy.minorGcCost
> sun.gc.policy.majorGcCost
> sun.gc.policy.mutatorCost
> sun.gc.policy.liveSpace
> sun.gc.policy.freeSpace
> sun.gc.policy.avgBaseFootprint
> sun.gc.policy.avgYoungLive
> sun.gc.policy.avgOldLive
> sun.gc.policy.gcTimeLimitExceeded
> sun.gc.policy.liveAtLastFullGc
> sun.gc.policy.majorPauseOldSlope
> sun.gc.policy.minorPauseOldSlope
> sun.gc.policy.majorPauseYoungSlope
> sun.gc.policy.minorPauseYoungSlope
> sun.gc.policy.majorCollectionSlope
> sun.gc.policy.minorCollectionSlope
> sun.gc.policy.scavengeSkipped
> sun.gc.policy.fullFollowsScavenge
> sun.gc.tlab.allocThreads
> sun.gc.tlab.fills
> sun.gc.tlab.maxFills
> sun.gc.tlab.alloc
> sun.gc.tlab.gcWaste
> sun.gc.tlab.maxGcWaste
> sun.gc.tlab.slowWaste
> sun.gc.tlab.maxSlowWaste
> sun.gc.tlab.fastWaste
> sun.gc.tlab.maxFastWaste
> sun.gc.tlab.slowAlloc
> sun.gc.tlab.maxSlowAlloc
> sun.gc.collector.0.name
> PSScavenge
> sun.gc.collector.0.invocations
> sun.gc.collector.0.time
> sun.gc.collector.0.lastEntryTime
> sun.gc.collector.0.lastExitTime
> sun.gc.collector.1.name
> PSMarkSweep
> sun.gc.collector.1.invocations
> sun.gc.collector.1.time
> sun.gc.collector.1.lastEntryTime
> sun.gc.collector.1.lastExitTime
> sun.threads.vmOperationTime
> sun.ci.adapterThread.method
> sun.ci.adapterThread.type
> sun.ci.adapterThread.time
> sun.ci.adapterThread.compiles
> sun.ci.compilerThread.0.method
> sun.ci.compilerThread.0.type
> sun.ci.compilerThread.0.time
> sun.ci.compilerThread.0.compiles
> sun.ci.compilerThread.1.method
> sun.ci.compilerThread.1.type
> sun.ci.compilerThread.1.time
> sun.ci.compilerThread.1.compiles
> sun.ci.threads
> java.ci.totalTime
> sun.ci.nativeTime
> sun.ci.osrTime
> sun.ci.standardTime
> sun.ci.totalBailouts
> sun.ci.totalInvalidates
> sun.ci.totalCompiles
> sun.ci.nativeCompiles
> sun.ci.osrCompiles
> sun.ci.standardCompiles
> sun.ci.osrBytes
> sun.ci.standardBytes
> sun.ci.nmethodSize
> sun.ci.nmethodCodeSize
> sun.ci.lastMethod
> org/hibernate/persister/entity/AbstractEntityPersister hasProxy
> sun.ci.lastFailedMethod
> sun.ci.lastInvalidatedMethod
> sun.ci.lastType
> sun.ci.lastSize
> sun.ci.lastFailedType
> sun.ci.lastInvalidatedType
> sun.os.hrt.frequency
> java.property.java.vm.specification.version
> java.property.java.vm.specification.name
> Java Virtual Machine Specification
> java.property.java.vm.specification.vendor
> Sun Microsystems Inc.
> java.property.java.vm.version
> 1.5.0_11-b03
> java.property.java.vm.name
> Java HotSpot(TM) Server VM
> java.property.java.vm.vendor
> Sun Microsystems Inc.
> java.property.java.vm.info
> mixed mode
> java.property.java.library.path
> /usr/local/jdk1.5.0_11/jre/lib/i386/server:/usr/local/jdk1.5.0_11/jre/lib/i386:/usr/local/jdk1.5.0_11/jre/../lib/i386:/usr/local/tomcat5/bin
>
> java.property.java.class.path
> :/usr/local/tomcat5/bin/bootstrap.jar:/usr/local/tomcat5/bin/commons-
> logging-api.jar
> java.property.java.endorsed.dirs
> /usr/local/tomcat5/common/endorsed
> java.property.java.ext.dirs
> /usr/local/jdk1.5.0_11/jre/lib/ext
> java.property.java.home
> /usr/local/jdk1.5.0_11/jre
> sun.property.sun.boot.class.path
> /usr/local/tomcat5/common/endorsed/rowset.jar:/usr/local/jdk1.5.0_11/jre/lib/rt.jar:/usr/local/jdk1.5.0_11/jre/lib/i18n.jar:/usr/local/jdk1.5.0_11/jre/lib/sunrsasign.jar:/usr/local/jdk1.5.0_11/jre/lib/jsse.jar:/usr/local/jdk1.5.0_11/jre/lib/jce.jar:/usr/local/jdk1.5.0_11/jre/lib/charsets.jar:/usr/local/jdk1.5.0_11/jre/classes
>
> sun.property.sun.boot.library.path
> /usr/local/jdk1.5.0_11/jre/lib/i386
> java.rt.vmFlags
> java.rt.vmArgs
> -Xms64m -Xmx200m -Xss512k -
> Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -
> Djava.util.logging.config.file=/alert/training/tomcatvw/conf/logging.properties-
> Dorg.xml.sax.driver=org.apache.xerces.parsers.SAXParser -
> Doracle.jdbc.V8Compatible=true -
> Doracledatabasemetadata.get_lob_precision=false -
> Djava.endorsed.dirs=/usr/local/tomcat5/common/endorsed -
> Dcatalina.base=/alert/training/tomcatvw -Dcatalina.home=/usr/local/tomcat5-
> Djava.io.tmpdir=/alert/training/tomcatvw/temp
> sun.rt.javaCommand
> org.apache.catalina.startup.Bootstrap start
> sun.rt.internalVersion
> Java HotSpot(TM) Server VM (1.5.0_11-b03 ) for linux-x86, built on Dec 15
> 2006 01:12:32 by java_re with gcc 3.2.1-7a (J2SE release)
> sun.os.hrt.ticks
>
>
>
> On 7/12/07, Ingo Krabbe <ik...@web.de> wrote:
> >
> >
> > We happend to have similar problems when starting with tomcat. Our main
> > error
> > was a failing connection to the database, while the connector had it's
> > retry
> > flag on. So the answer to each request was, trying to connect to a
> > unconnectable database until the timeout has been reached, which is too
> > long
> > for any busy site of course.
> >
> > Before you examine all your threads you should test your application for
> > such
> > errors that delay the answer to requests.
> >
> > Maybe you should also try to build a test setup, answering very simple
> > to your
> > requests (hello, world) and push in one application module each time to
> > see
> > at which state your application breaks.
> >
> > When you get this error very fast the error should occure at one quite
> > central
> > point in your code.
> >
> > Also consult access and error logs of the tomcat process (catalina.outand
> > similar).
> >
> > Writing your own log files by your jsp pages is also quite helpfull
> > sometimes.
> >
> > Am Donnerstag, 12. Juli 2007 15:02 schrieb André Vila Cova:
> > > Hi!
> > >
> > > I've this two processes:
> > >
> > > tomcat 6404 0.0 2.6 484396 105456 ? Sl 01:05 0:14
> > > /usr/local/java1.5/bin/java -Xms64m -Xmx200m -Xss512k -
> > > Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -
> > > Djava.util.logging.conf
> > > tomcat 6555 0.1 3.8 516420 154452 ? Sl 01:09 0:39
> > > /usr/local/java1.5/bin/java -Xms64m -Xmx200m -Xss512k -
> > > Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -
> > > Djava.util.logging.conf
> > >
> > > Output is null when I execute the following command:
> > > [root@alertapp01 ~]# kill -QUIT 6404
> > > [root@alertapp01 ~]#
> > >
> > > How can I see what thread is doing?
> > >
> > > Thank You
> > >
> > > On 7/11/07, Titi Wangsa <bl...@gmail.com> wrote:
> > > > probably some threads are performing database operation
> > > > and it takes too long so new threads are being spawned,
> > > > the new threads are also taking too long, so newer threads are being
> > > > spawned.
> > > > too much spawning, that is what is causing the limit break.
> > > >
> > > > On 7/12/07, André Vila Cova <andremailinglist@gmail.com > wrote:
> > > > > I don't think so... I will see..but, why i get the error?
> > > > > SEVERE: All threads (200) are currently *busy*, waiting. *Increase
> > > > >
> > > > > On 7/11/07, Mladen Turk < mladen.turk@gmail.com> wrote:
> > > > > > André Vila Cova wrote:
> > > > > > > Hello!
> > > > > > >
> > > > > > > I get lot of times the following error:
> > > > > > >
> > > > > > > SEVERE: All threads (200) are currently *busy*, waiting.
> > *Increase
> > > > > > > maxThreads*
> > > > > > > **
> > > > > > > *Strange is that i've configured in server.xml the following
> > > > > > > (maxThreads=400):*
> > > > > > > *
> > > > > >
> > > > > > You have probably done that for a wrong connector.
> > > > > >
> > > > > > Regards,
> > > > > > Mladen.
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To start a new topic, e-mail: users@tomcat.apache.org
> > > > > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > > > > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> > --
> > ==================================================
> > Ingo Krabbe ASK UNIX Systems
> > Burggrafenstraße 3
> > 44139 Dortmund
> >
> > Telefon 0231 4770185
> > FAX 0231 4770186
> > E-Mail ikrabbe.ask@web.de
> > Fingerprint EE5A 6533 EE5E 8F66 EC20 C56A 35FC
> > B736 18FD EB5A
> > ==================================================
> >
>
>
Re: Tomcat - All threads (200) are currently busy
Posted by Ingo Krabbe <ik...@web.de>.
We happend to have similar problems when starting with tomcat. Our main error
was a failing connection to the database, while the connector had it's retry
flag on. So the answer to each request was, trying to connect to a
unconnectable database until the timeout has been reached, which is too long
for any busy site of course.
Before you examine all your threads you should test your application for such
errors that delay the answer to requests.
Maybe you should also try to build a test setup, answering very simple to your
requests (hello, world) and push in one application module each time to see
at which state your application breaks.
When you get this error very fast the error should occure at one quite central
point in your code.
Also consult access and error logs of the tomcat process (catalina.out and
similar).
Writing your own log files by your jsp pages is also quite helpfull sometimes.
Am Donnerstag, 12. Juli 2007 15:02 schrieb André Vila Cova:
> Hi!
>
> I've this two processes:
>
> tomcat 6404 0.0 2.6 484396 105456 ? Sl 01:05 0:14
> /usr/local/java1.5/bin/java -Xms64m -Xmx200m -Xss512k -
> Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -
> Djava.util.logging.conf
> tomcat 6555 0.1 3.8 516420 154452 ? Sl 01:09 0:39
> /usr/local/java1.5/bin/java -Xms64m -Xmx200m -Xss512k -
> Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -
> Djava.util.logging.conf
>
> Output is null when I execute the following command:
> [root@alertapp01 ~]# kill -QUIT 6404
> [root@alertapp01 ~]#
>
> How can I see what thread is doing?
>
> Thank You
>
> On 7/11/07, Titi Wangsa <bl...@gmail.com> wrote:
> > probably some threads are performing database operation
> > and it takes too long so new threads are being spawned,
> > the new threads are also taking too long, so newer threads are being
> > spawned.
> > too much spawning, that is what is causing the limit break.
> >
> > On 7/12/07, André Vila Cova <an...@gmail.com> wrote:
> > > I don't think so... I will see..but, why i get the error?
> > > SEVERE: All threads (200) are currently *busy*, waiting. *Increase
> > >
> > > On 7/11/07, Mladen Turk <ml...@gmail.com> wrote:
> > > > André Vila Cova wrote:
> > > > > Hello!
> > > > >
> > > > > I get lot of times the following error:
> > > > >
> > > > > SEVERE: All threads (200) are currently *busy*, waiting. *Increase
> > > > > maxThreads*
> > > > > **
> > > > > *Strange is that i've configured in server.xml the following
> > > > > (maxThreads=400):*
> > > > > *
> > > >
> > > > You have probably done that for a wrong connector.
> > > >
> > > > Regards,
> > > > Mladen.
> > > >
> > > > ---------------------------------------------------------------------
> > > > To start a new topic, e-mail: users@tomcat.apache.org
> > > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > > For additional commands, e-mail: users-help@tomcat.apache.org
--
==================================================
Ingo Krabbe ASK UNIX Systems
Burggrafenstraße 3
44139 Dortmund
Telefon 0231 4770185
FAX 0231 4770186
E-Mail ikrabbe.ask@web.de
Fingerprint EE5A 6533 EE5E 8F66 EC20 C56A 35FC
B736 18FD EB5A
==================================================
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat - All threads (200) are currently busy
Posted by Bill Au <bi...@gmail.com>.
Take a thread dump of the JVM:
http://java.sun.com/developer/technicalArticles/Programming/Stacktrace/
Bill
On 7/12/07, André Vila Cova <an...@gmail.com> wrote:
>
> Hi!
>
> I've this two processes:
>
> tomcat 6404 0.0 2.6 484396 105456 ? Sl 01:05 0:14
> /usr/local/java1.5/bin/java -Xms64m -Xmx200m -Xss512k -
> Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -
> Djava.util.logging.conf
> tomcat 6555 0.1 3.8 516420 154452 ? Sl 01:09 0:39
> /usr/local/java1.5/bin/java -Xms64m -Xmx200m -Xss512k -
> Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -
> Djava.util.logging.conf
>
> Output is null when I execute the following command:
> [root@alertapp01 ~]# kill -QUIT 6404
> [root@alertapp01 ~]#
>
> How can I see what thread is doing?
>
> Thank You
>
>
>
> On 7/11/07, Titi Wangsa <bl...@gmail.com> wrote:
> >
> > probably some threads are performing database operation
> > and it takes too long so new threads are being spawned,
> > the new threads are also taking too long, so newer threads are being
> > spawned.
> > too much spawning, that is what is causing the limit break.
> >
> > On 7/12/07, André Vila Cova <an...@gmail.com> wrote:
> > > I don't think so... I will see..but, why i get the error?
> > > SEVERE: All threads (200) are currently *busy*, waiting. *Increase
> > >
> > >
> > > On 7/11/07, Mladen Turk <ml...@gmail.com> wrote:
> > > >
> > > > André Vila Cova wrote:
> > > > > Hello!
> > > > >
> > > > > I get lot of times the following error:
> > > > >
> > > > > SEVERE: All threads (200) are currently *busy*, waiting. *Increase
> > > > > maxThreads*
> > > > > **
> > > > > *Strange is that i've configured in server.xml the following
> > > > > (maxThreads=400):*
> > > > > *
> > > > >
> > > >
> > > > You have probably done that for a wrong connector.
> > > >
> > > > Regards,
> > > > Mladen.
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To start a new topic, e-mail: users@tomcat.apache.org
> > > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > > For additional commands, e-mail: users-help@tomcat.apache.org
> > > >
> > > >
> > >
> >
>
Re: Tomcat - All threads (200) are currently busy
Posted by André Vila Cova <an...@gmail.com>.
Hi!
I've this two processes:
tomcat 6404 0.0 2.6 484396 105456 ? Sl 01:05 0:14
/usr/local/java1.5/bin/java -Xms64m -Xmx200m -Xss512k -
Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -
Djava.util.logging.conf
tomcat 6555 0.1 3.8 516420 154452 ? Sl 01:09 0:39
/usr/local/java1.5/bin/java -Xms64m -Xmx200m -Xss512k -
Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -
Djava.util.logging.conf
Output is null when I execute the following command:
[root@alertapp01 ~]# kill -QUIT 6404
[root@alertapp01 ~]#
How can I see what thread is doing?
Thank You
On 7/11/07, Titi Wangsa <bl...@gmail.com> wrote:
>
> probably some threads are performing database operation
> and it takes too long so new threads are being spawned,
> the new threads are also taking too long, so newer threads are being
> spawned.
> too much spawning, that is what is causing the limit break.
>
> On 7/12/07, André Vila Cova <an...@gmail.com> wrote:
> > I don't think so... I will see..but, why i get the error?
> > SEVERE: All threads (200) are currently *busy*, waiting. *Increase
> >
> >
> > On 7/11/07, Mladen Turk <ml...@gmail.com> wrote:
> > >
> > > André Vila Cova wrote:
> > > > Hello!
> > > >
> > > > I get lot of times the following error:
> > > >
> > > > SEVERE: All threads (200) are currently *busy*, waiting. *Increase
> > > > maxThreads*
> > > > **
> > > > *Strange is that i've configured in server.xml the following
> > > > (maxThreads=400):*
> > > > *
> > > >
> > >
> > > You have probably done that for a wrong connector.
> > >
> > > Regards,
> > > Mladen.
> > >
> > > ---------------------------------------------------------------------
> > > To start a new topic, e-mail: users@tomcat.apache.org
> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@tomcat.apache.org
> > >
> > >
> >
>
Re: Tomcat - All threads (200) are currently busy
Posted by Titi Wangsa <bl...@gmail.com>.
probably some threads are performing database operation
and it takes too long so new threads are being spawned,
the new threads are also taking too long, so newer threads are being spawned.
too much spawning, that is what is causing the limit break.
On 7/12/07, André Vila Cova <an...@gmail.com> wrote:
> I don't think so... I will see..but, why i get the error?
> SEVERE: All threads (200) are currently *busy*, waiting. *Increase
>
>
> On 7/11/07, Mladen Turk <ml...@gmail.com> wrote:
> >
> > André Vila Cova wrote:
> > > Hello!
> > >
> > > I get lot of times the following error:
> > >
> > > SEVERE: All threads (200) are currently *busy*, waiting. *Increase
> > > maxThreads*
> > > **
> > > *Strange is that i've configured in server.xml the following
> > > (maxThreads=400):*
> > > *
> > >
> >
> > You have probably done that for a wrong connector.
> >
> > Regards,
> > Mladen.
> >
> > ---------------------------------------------------------------------
> > To start a new topic, e-mail: users@tomcat.apache.org
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
Re: Tomcat - All threads (200) are currently busy
Posted by André Vila Cova <an...@gmail.com>.
I don't think so... I will see..but, why i get the error?
SEVERE: All threads (200) are currently *busy*, waiting. *Increase
On 7/11/07, Mladen Turk <ml...@gmail.com> wrote:
>
> André Vila Cova wrote:
> > Hello!
> >
> > I get lot of times the following error:
> >
> > SEVERE: All threads (200) are currently *busy*, waiting. *Increase
> > maxThreads*
> > **
> > *Strange is that i've configured in server.xml the following
> > (maxThreads=400):*
> > *
> >
>
> You have probably done that for a wrong connector.
>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat - All threads (200) are currently busy
Posted by Mladen Turk <ml...@gmail.com>.
André Vila Cova wrote:
> Hello!
>
> I get lot of times the following error:
>
> SEVERE: All threads (200) are currently *busy*, waiting. *Increase
> maxThreads*
> **
> *Strange is that i've configured in server.xml the following
> (maxThreads=400):*
> *
>
You have probably done that for a wrong connector.
Regards,
Mladen.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org