It looks like this is a regression in 1.2.31 - the socket shutdown
code that drained the response message from the AJP socket before
closing it was mis-counting the bytes read, causing a CPU busy loop
until it hit a 30 second cap on lingering byte reads.
I've committed a fix for 1.2.32 and also ca
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 5/14/2011 4:01 PM, André Warnier wrote:
> eurotrans-Verlag wrote:
>> However I would expect write() to always throw an IOException when the
>> connection to the client is aborted,
>
> Remember, there are 2 separate connections : the connec
Hi Tim,
> This sounds like
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50839
> If you can capture a TRACE level log form the Tomcat Connector
> (configure in isapi_redirect.properties) and attach it to the bug,
> I'll take a look.
>
> cheers
> tim
Thanks! I will attach a Trace level lo
nd cancels the download, the IIS Worker
> process (w3wp.exe) will have 100% CPU usage for about 30 seconds. However if
> the download is completed normally (not canceled), everything is fine and
> the CPU usage will not go up that far.
>
> The exact Components used are:
> Wind
eurotrans-Verlag wrote:
Hi André, thanks for your reply.
To figure out if this is what's happening, you could do some logging at
the servlet end,
to see if it keeps sending data even when the client has canceled, or
if it itself gets
some stop indication from the isapi_redirector (also a closed
Hi André, thanks for your reply.
> To figure out if this is what's happening, you could do some logging at
> the servlet end,
> to see if it keeps sending data even when the client has canceled, or
> if it itself gets
> some stop indication from the isapi_redirector (also a closed socket
> e.g.).
cancels the download, the IIS Worker
process (w3wp.exe) will have 100% CPU usage for about 30 seconds. However if
the download is completed normally (not canceled), everything is fine and
the CPU usage will not go up that far.
The exact Components used are:
Windows Server 2008 SP2 (32 bit) with IIS
IIS Worker
process (w3wp.exe) will have 100% CPU usage for about 30 seconds. However if
the download is completed normally (not canceled), everything is fine and
the CPU usage will not go up that far.
The exact Components used are:
Windows Server 2008 SP2 (32 bit) with IIS 7.0,
Sun JDK 1.6.0_25
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Felix,
On 5/4/2011 1:07 AM, Felix Schumacher wrote:
> It could've been the garbage collector itself. Just yesterday I had
> an oom on permgen, which lead to a major-gc loop. I could see the
> loop nicely as I had enabled logging of gc activity with
>
Tomcat, the shutdown failed and I took a
>>>>> thread dump which included the one non-trivial thread shown below.
>>>>>
>>>>> I haven't looked at the code yet to see if there is some kind of
>loop
>>>>> around this code, bu
ad shown below.
>>>>
>>>> I haven't looked at the code yet to see if there is some kind of loop
>>>> around this code, but top reported 100% CPU usage from this process so I
>>>> suspect something like that was happening.
>>>>
>&g
n undeploy-related leak).
>>> When attempting to bounce Tomcat, the shutdown failed and I took a
>>> thread dump which included the one non-trivial thread shown below.
>>>
>>> I haven't looked at the code yet to see if there is some kind of loop
>>>
which included the one non-trivial thread shown below.
I haven't looked at the code yet to see if there is some kind of loop
around this code, but top reported 100% CPU usage from this process so I
suspect something like that was happening.
We are using TC 6.0.32 on Debian Lenny and Sun/Orac
thread dump which included the one non-trivial thread shown below.
>
> I haven't looked at the code yet to see if there is some kind of loop
> around this code, but top reported 100% CPU usage from this process so I
> suspect something like that was happening.
>
> We are using TC
non-trivial thread shown below.
I haven't looked at the code yet to see if there is some kind of loop
around this code, but top reported 100% CPU usage from this process so I
suspect something like that was happening.
We are using TC 6.0.32 on Debian Lenny and Sun/Oracle 32-bit
1.6.0_22-b04 S
--
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
--
View this message in context:
http://old.nabble.com/Tomcat-100--CPU-usage-after-moving-from-Java-5-to-6-tp27305110p28527724
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Subject: Re: Tomcat 100% CPU usage after moving from Java 5 to 6
>
> It's interesting that there's no timing data for that last statement.
> It /is/ possible this is where the JVM went down. (Did
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse,
On 2/2/2010 3:23 AM, Jesse Klaasse wrote:
> Christopher Schultz-2 wrote:
>>
>> Can you give us a timestamp for when the trouble started? Reading GC
>> output is pretty tedious.
>>
>
> I believe the trouble started around 15 - 20 minutes before
>
> Well, as I said, Tomcat is working much more stable now than it did before.
> However, once in a few days it still becomes unresponsive, while CPU usage
> stays incredibly low.
Unresponsive, meaning what, exactly? If the CPU is idle, but your
webapp isn't returning a response... it seems to i
s predictable/repetitive) traffic on
the production environment, I guess..
--
View this message in context:
http://old.nabble.com/Tomcat-100--CPU-usage-after-moving-from-Java-5-to-6-tp27305110p27416818.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse,
On 2/1/2010 5:22 AM, Jesse Klaasse wrote:
>
> In the meantime, the environment has been much more stable than it was before
> the move to Java 6 and the new JVM options. However, a few minutes ago,
> Tomcat became completely unresponsive, whil
://old.nabble.com/Tomcat-100--CPU-usage-after-moving-from-Java-5-to-6-tp27305110p27402032.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional
2010/1/26 Leon Rosenberg
> Another customer of mine was playing with gc settings for nearly a
> year, because his tomcats collection times went higher and higher, and
> after a short look at the heap dump with jmap and jhat, we found out
> that he had 100.000.000 uncollectable garbage objects in
oc (fixes sized generation spaces lead to
100% cpu usage and continuous full gcs, some performance options are
extremely vm version specific and so on).
Among the sites of my customers, one site is serving more than 500
requests per second in a single tomcat with only following options:
-Xmx16
usage is as low as it is now,
I have decided to give it a try.
Anyway, thanks again!
--
View this message in context:
http://old.nabble.com/Tomcat-100--CPU-usage-after-moving-from-Java-5-to-6-tp27305110p27324793.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
> From: Jesse Klaasse [mailto:jesse.klaa...@indicia.nl]
> Subject: Re: Tomcat 100% CPU usage after moving from Java 5 to 6
>
> I found the following article particularly useful:
> http://confluence.atlassian.com/display/DOC/Garbage+Collector+Performance+Issues
Unfortunately, tha
in JDK
6:
http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
I thought, I'd just let you all know!
--
View this message in context:
http://old.nabble.com/Tomcat-100--CPU-usage-after-moving-from-Java-5-to-6-tp27305110p27322864.html
Sent from the Tomcat - User mailing list a
Jesse Klaasse wrote:
I have now fixed the infinite loop, and again did the update from Java 5 to
Java 6. This time all seems to be working like a charm!
Along with fixing the infinite loop, I have dug a little deeper into the JVM
arguments. I found the following article particularly useful:
http
led flag?
So, still some research to be done.
In the meantime I am very pleased with the results. Tomcat's CPU usage seems
significantly lower than before (it's average seems about 10% now - which
was 30-40% before) - scary!
--
View this message in context:
http://old.nabble.com/Tomc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse,
On 1/25/2010 8:25 AM, Jesse Klaasse wrote:
> I don't know what you mean exactly by "re-intrant"
Re-entrant (never seen it as "re-intrant") means that more than one
thread of execution might be running the same code concurrently. I've
never hea
Jesse Klaasse wrote:
Hi Leon,
I don't know what you mean exactly by "re-intrant", but your comment points
out I have created an endless while-loop! Apart from moving to Java 6, I had
commented out some lines to reduce logging, not noticing I had created an
endless loop by doing so. I only did th
Jesse Klaasse wrote:
...
ctory -Dcom.sun.management.jmxremote -XX:MaxPermSize=512m
-Xloggc:D:\logs\gc\tomcat-gc.log -XX:+PrintGCDetails -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSClassUnloadingEnabled
-XX:+CMSPermGenSweepingEnabled -Xms4096m -Xmx10240m
Apart from your basic
intln("Workflow/doAction: oid=" +
> ((ObjectId)oidIterator.next()).getKey());
> }
> and you are modifying this vector at multiple places in the same class.
>
> You should probably unit-test this code for concurrency.
>
> regards
> Leon
>
va 4
>> and 5?
>>
>
> I forgot the attachments, sorry!
> http://old.nabble.com/file/p27306041/DQWorkflow.java DQWorkflow.java
> http://old.nabble.com/file/p27306041/Workflow.java Workflow.java
> --
> View this message in context:
> http://old.nabble.com/Tomcat-100--CPU-usage-aft
ile/p27306041/Workflow.java Workflow.java
--
View this message in context:
http://old.nabble.com/Tomcat-100--CPU-usage-after-moving-from-Java-5-to-6-tp27305110p27306041.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
s are from our company, written by the
programmer who worked on this project before me. I have attached the two
files for further examination.
I have noticed the performWorkflowAction method in DQWorkflow is not
synchronized and uses Vectors and Iterators. Could this be a possible
problem? Even though
I'm not sure how to
interpret it correctly), and it's overwritten when Tomcat is restarted, so
there's really nothing I can say about that. Do you suspect any problems
there?
--
View this message in context:
http://old.nabble.com/Tomcat-100--CPU-usage-after-moving-from-Java-5-to-6-t
P.S. Your tomcat is writing gc logs, please attach them next time.
On Mon, Jan 25, 2010 at 12:31 PM, Leon Rosenberg
wrote:
> take a look on threads
> ajp-8009-2
> ajp-8009-18
> ajp-8009-30
> ajp-8009-38
>
> they are all seem to be either in an infinite loop:
> at java.util.AbstractList$Itr
take a look on threads
ajp-8009-2
ajp-8009-18
ajp-8009-30
ajp-8009-38
they are all seem to be either in an infinite loop:
at java.util.AbstractList$Itr.hasNext(AbstractList.java:339)
at
nl.indicia.vip.framework.util.Workflow.performWorkflowAction(Workflow.java:166)
at
nl.
On 25/01/2010 11:08, Jesse Klaasse wrote:
I am running a production environment for a website (over half a million
hits per day), using Tomcat 5.5.20 (I'm stuck to that version due to
support restrictions) behind IIS 6 using JK connector 1.2.28,
tcnative-1.dll (1.1.19) on Windows Server 2003 R2 E
g, 15 oktober 2008 om 20:22 uur schreef Tomcat Users List
:
Subject: Re: NIO 100% CPU usage
Date: Wed Oct 15 20:22:43 CEST 2008
From: Filip Hanik - Dev Lists <[EMAIL PROTECTED]>
ok, when you reproduce it, you don't really need a profiler,
you can do a top with thr
Jerome Jar schrieb:
> Ronald,
>
> thread dumps contain the native ID of threads, and ps can output such IDs as
> well, so you can match the output together. Been there, done that.
L flag for ps shows all threads and contains thread numbers, usually
numerically starting above the PID, but IDs of t
;>
>> Filip
>>
>>
>> Matías Rojas wrote:
>> > It's 6.0.18
>> >
>> > -Original Message-
>> > From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] > Sent:
>> miércoles, 15 de octubre de 2008 07:25 p.m.
>> > To: Tomcat
bject: Re: NIO 100% CPU usage
Date: Wed Oct 15 20:22:43 CEST 2008
From: Filip Hanik - Dev Lists <[EMAIL PROTECTED]>
ok, when you reproduce it, you don't really need a profiler,
you can do a top with threads on, or a ps -efL, and from those, you can look
into a thread dump
I'
fhanik at apache dot org
Filip
Matías Rojas wrote:
It's 6.0.18
-Original Message-
From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
Sent: miércoles, 15 de octubre de 2008 07:25 p.m.
To: Tomcat Users List
Subject: Re: NIO 100% CPU usage
what version of tomcat are you using?
It's 6.0.18
-Original Message-
From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
Sent: miércoles, 15 de octubre de 2008 07:25 p.m.
To: Tomcat Users List
Subject: Re: NIO 100% CPU usage
what version of tomcat are you using?
Filip
Matías Rojas wrote:
> Hi Filip,
> Than
what version of tomcat are you using?
Filip
Matías Rojas wrote:
Hi Filip,
Thanks for your response.
I can only reproduce it on production, where we are running a Linux 2.6
Kernel with JDK 6 update 7. After a high load it is still running at 100%
CPU usage (sometimes 200% or 300% taking 2 or 3
Hi Filip,
Thanks for your response.
I can only reproduce it on production, where we are running a Linux 2.6
Kernel with JDK 6 update 7. After a high load it is still running at 100%
CPU usage (sometimes 200% or 300% taking 2 or 3 cores).
Today I'll try to do some profiling to detect the
hi Matías,
I have not yet found a way to reproduce it to put in a work around so
even though its not fixed in 1.5 and 1.6, we can make it work.
If you want to work with me, we can make that happen, assuming you have
a way to reproduce this
Filip
Matías Rojas wrote:
Hello,
I'm experiencing
Hello,
I'm experiencing a problem with NIO in Tomcat, maybe related to this issue:
Selector doesn't block on Selector.select(timeout) (lnx)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6403933
I'm using JDK 6 update 7 and it seems not to be fixed, does anybody have the
same problem
Hi, Lindsay,
Sorry for my ignorance, but seeing that you were trying to locate the
thread using "PID", I think perhaps it's wrong. I have the same
experience identifying such a CPU utilization issue on a Debian box
using a 2.6.x version kernel. I cannot recall whether on a 2.4.x
kernal linux box y
Thank you to the several people who made suggestions, either on the list
or by direct email!
I think I have solved the problem by simply using the -server option to
java when starting tomcat. By default tomcat uses the default VM, which
for Sun JDK1.5 is the client VM. By default the client
> From: Lindsay Patten [mailto:[EMAIL PROTECTED]
> Subject: Re: 100% cpu usage by "VM Thread" in tomcat
>
> I need to figure out how to reproduce the situation out of
> the production server to see how I can use it...
For an initial check, set -Dcom.sun.management
ut of the production server to see how I can
use it...
Further suggestions very welcome!
Thanks,
Lindsay
Caldarale, Charles R wrote:
From: Lindsay Patten [mailto:[EMAIL PROTECTED]
Subject: 100% cpu usage by "VM Thread" in tomcat
Expecting to find that I had some error in my weba
> From: Lindsay Patten [mailto:[EMAIL PROTECTED]
> Subject: 100% cpu usage by "VM Thread" in tomcat
>
> Expecting to find that I had some error in my webapp I did a
> few thread dumps, but assuming that nid in the thread dump
> corresponds to pid from ps I fou
On 9/21/07, Lindsay Patten <[EMAIL PROTECTED]> wrote:
[ ...stuff elided...]
>
> If I look at the system status using the Tomcat manager webapp there are
> often requests listed with ridiculously large values in the Time column,
> several hundred seconds for jsp pages that only take a fraction of a
I am looking for information on how to debug a problem. Any pointers to
documentation, suggestions of approaches etc. would be much appreciated.
I am having a problem with my tomcat server periodically going into a
state where it is using up all the available cpu and providing very slow
respon
ing used but sadly I am no wiser. None of my code
> appears to be eating CPU time (and neither do any of Tomcat's Java
> threads).
>
> I'd be really grateful if someone could give me some ideas about how to go
> about troubleshooting this.
>
> Cheers,
> Richard.
&
bout troubleshooting this.
Cheers,
Richard.
--
View this message in context:
http://www.nabble.com/100--CPU-usage-tf4166493.html#a11854043
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To start a
I don't see how
>> >> you're not going to get an error event in that particular case.
>> >> However, I can't test it personally, so maybe you can look into
>> this a
>> >> bit deeper (otherwise, most likely Filip will).
>> >>
>> >> R
#x27;re not going to get an error event in that particular case.
>> >> However, I can't test it personally, so maybe you can look into
>> this a
>> >> bit deeper (otherwise, most likely Filip will).
>> >>
>> >> Rémy
>> >>
>
gt;
>> Rémy
>>
>
> No. Compiling and enabling the APR connector instead of the NIO
> connector made the problem go away. There were still no ERROR events
> sent after the client disconnect (I guess the connection might timeout
> sometime later), but the original problem of 100%
> No. Compiling and enabling the APR connector instead of the NIO
> connector made the problem go away. There were still no ERROR events
> sent after the client disconnect (I guess the connection might timeout
> sometime later), but the original problem of 100% CPU usage is gone.
ok, le
look into this a
bit deeper (otherwise, most likely Filip will).
Rémy
No. Compiling and enabling the APR connector instead of the NIO
connector made the problem go away. There were still no ERROR events
sent after the client disconnect (I guess the connection might timeout
sometime later), but
roblem of 100% CPU usage is gone.
I think this is still a problem (or maybe it's normal that you would
only get a timeout later, but I doubt it ...).
Maybe you can see what are the status codes which are reported by the
poller by adding some logging: t
bit deeper (otherwise, most likely Filip will).
Rémy
No. Compiling and enabling the APR connector instead of the NIO
connector made the problem go away. There were still no ERROR events
sent after the client disconnect (I guess the connection might timeout
sometime later), but the original problem of 100% CPU usage is gone.
- elias
On 4/6/07, Elias Naur <[EMAIL PROTECTED]> wrote:
I'm aware that a correct implementation must empty the buffer on a
READ event, but as I stated in the original post, a READ event is
never received (not even when the client forces a disconnect), only
the initial BEGIN event, so had I included a re
the client, let alone
>> > ended the connection. However, ending the connection by ctrl-c'ing
>> > wget (or pressing stop in firefox) results in tomcat suddenly jumps
>> > from almost no CPU usage to 100% usage until I kill it. I've included
>> > a sample
gt; expected, since I haven't sent anything back to the client, let alone
> ended the connection. However, ending the connection by ctrl-c'ing
> wget (or pressing stop in firefox) results in tomcat suddenly jumps
> from almost no CPU usage to 100% usage until I kill it. I've inclu
e included
a sample stack trace obtained with jstack while tomcat was at 100% CPU
usage.
Some info:
1. I'm running tomcat 6.0.10 on JDK 1.6
2. Only one BEGIN event is seen by the event(CometEvent event) method,
no ERRORs or READs are received.
3. The tomcat is running locally, so I've only
#x27;t sent anything back to the client, let alone
> ended the connection. However, ending the connection by ctrl-c'ing
> wget (or pressing stop in firefox) results in tomcat suddenly jumps
> from almost no CPU usage to 100% usage until I kill it. I've included
> a sample stack t
essing stop in firefox) results in tomcat suddenly jumps
from almost no CPU usage to 100% usage until I kill it. I've included
a sample stack trace obtained with jstack while tomcat was at 100% CPU
usage.
Some info:
1. I'm running tomcat 6.0.10 on JDK 1.6
2. Only one BEGIN event is seen
m almost no CPU usage to 100% usage until I kill it. I've included
a sample stack trace obtained with jstack while tomcat was at 100% CPU
usage.
Some info:
1. I'm running tomcat 6.0.10 on JDK 1.6
2. Only one BEGIN event is seen by the event(CometEvent event) method,
no ERRORs or READs are r
73 matches
Mail list logo
