Hi,
Thanks for your replies and help, Chris and Konstantin.
I watch below link from now on.
Best Regards,
Takeshi Yoshida
(2012/05/31 20:56), Konstantin Kolinko wrote:
2012/5/30 Takeshi.Yoshida:
Hi,
I installed Tomcat7.0.27.exe on Windows7 and Windows2008R2.
The Tomcat almost works fine.
How
2012/5/30 Takeshi.Yoshida :
> Hi,
>
> I installed Tomcat7.0.27.exe on Windows7 and Windows2008R2.
> The Tomcat almost works fine.
> However, when I right click on the Tomcat service icon on system tray
> and select menu "Thread Dump",
> I get a windows message and it's saying:
> "The system can not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Takeshi,
On 5/30/12 11:44 AM, Takeshi.Yoshida wrote:
> I installed Tomcat7.0.27.exe on Windows7 and Windows2008R2. The
> Tomcat almost works fine. However, when I right click on the Tomcat
> service icon on system tray and select menu "Thread Dump", I
On 4 June 2010 06:08, suchismitasuchi wrote:
>
> Thanks a lot.
> What will be the workaround for this?
It looks like a bug in your application, so the solution is to fix the
bug in your application.
Asking the Tomcat list how to fix your web application just because
it's hosted in Tomcat is rath
> From: suchismitasuchi [mailto:suchismitasu...@rediffmail.com]
> Subject: Thread Dump
>
> Can you please tell whether there is any problem with the
> below thread dump?
Probably. You've got lots of threads in this condition:
> "http-8000-Processor25" daemon prio=1 tid=0x2aaab41eeb90 nid=0
omairkhawaja wrote:
1) The Tomcat Manager that ships with 5.5.20 will continue to give the "The
system can not find the
file specified. Unable to open the Event Mutex" error message even when I
connect with the /console option
Use the tomcat5.exe and tomcat5w.exe from the
more recent version
Caldarale, Charles R wrote:
(BTW, it's Tomcat that runs as a service, not any given webapp.)
Nitpick : it's the JVM, not Tomcat.
Nitpick to the nitpick : it's the exe wrapper, not the JVM.
-
To unsubscribe, e-mail: users-un
> From: omairkhawaja [mailto:omairkhaw...@gmail.com]
>> Subject: Re: Thread dump on Tomcat 5.5.20 running as a service
>
>> I was initially running tomcat with the -Xrs JVM flag
>
> I'm curious; how did you set that for the service?
>
>
>> - what are the impli
> From: omairkhawaja [mailto:omairkhaw...@gmail.com]
> Subject: Re: Thread dump on Tomcat 5.5.20 running as a service
> I was initially running tomcat with the -Xrs JVM flag
I'm curious; how did you set that for the service?
> - what are the implications of removing the -X
Just to add: I'm using JDK 1.5
Thank you for your very prompt replies... There's one additional question
that I had ... I was initially running tomcat with the -Xrs JVM flag... but
if I try to take a thread dump, the Tomcat process crashes and I get
nothing... if I remove the VM flag, I can take
On 12.06.2009 15:00, Mark Thomas wrote:
> omairkhawaja wrote:
>> My question is though: is it guaranteed that the version of procrun that
>> ships with tomcat6 is completely compatible with tomcat 5.5.20?
>
> Yes. The same binaries work with all Tomcat versions. We just change the
> file name to r
omairkhawaja wrote:
> My question is though: is it guaranteed that the version of procrun that
> ships with tomcat6 is completely compatible with tomcat 5.5.20?
Yes. The same binaries work with all Tomcat versions. We just change the
file name to reflect the service name.
Mark
> From: Pieter Temmerman [mailto:ptemmerman@sadiel.es]
> Subject: RE: Thread dump analysis
>
> And what about Tomcat 5 with JDK6?
I don't run Tomcat 5 much anymore, but what little I have done with it seems to
be fine on JDK 6.
- Chuck
THIS COMMUNICATION MAY CONTAIN CO
Charles, List,
>Hmmm... could be a JVM bug, or might be a conflict with classes in your
>webapp. Do you happen to have some XML-related jars in >your webapp or
>otherwise visible to that branch of the classloader tree? (I guess you
>answered that below.)
Well, actually, the developers also i
> From: Pieter Temmerman [mailto:ptemmerman@sadiel.es]
> Subject: Re: Thread dump analysis
>
> Now, I don't know why (since I'm a noob programmer), but it seems that
> the implementation of Xerces that is included in JDK6 is causing the
> application to hang.
Hm
Hi.
For all of you who were so kind to respond to my problem a few days ago,
and for others who'd like to know, I think I have found the problem.
As mentioned in earlier mails, the application I monitor hangs after a
random amount of time. Using jconsole and virtualvm I managed to detect
the thre
Hi Chuck
>> Could it be that Tomcat ran out of connectors (maxThreads
>> was hit) and after a while they get closed by the timeout?
>Depends on how your DB connector pool is configured.
I was actually referring to the limit of http connections, set by maxThreads.
>> This could be a plausible e
> From: Pieter Temmerman [mailto:ptemmerman@sadiel.es]
> Subject: Re: Thread dump analysis
>
> Could it be that Tomcat ran out of connectors (maxThreads
> was hit) and after a while they get closed by the timeout?
Depends on how your DB connector pool is configured.
&g
> Do I understand you correctly, that after you killed the first tomcat
> (in my understanding the one which fires soap requests, tomcat 5) than
> all the RUNNABLE threads in the second tomcat (the one that answers
> soap, tomcat 6 with xfire) went away and it (tomcat) was idle?
No, I did not res
Thanks Chris,
I just bumped into a very nice plugin for Jconsole called "TopThread".
It's a linux top alike and shows the CPU usage of all threads.
This only confirms what I figured out before, there are two threads
taking up all CPU. See below for their stack trace:
com.sun.org.apache.xerces.int
I omit the whole quoting to save traffic for clarity.
Do I understand you correctly, that after you killed the first tomcat
(in my understanding the one which fires soap requests, tomcat 5) than
all the RUNNABLE threads in the second tomcat (the one that answers
soap, tomcat 6 with xfire) went awa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pieter,
Pieter Temmerman wrote:
> Memory usage looks healthy, but CPU usage goes sky high (mainly caused
> by the Java Tomcat process).
That's interesting. Looking at your thread dump snippet, it looks like
your database connection pool is exhausted.
>If the threadMax would be too low in the connector, wouldn't the
> "freeze" be over once there are free connections? And also, how can a
> small threadMax make a thread hang? For example the one that is trying
> to read an XML file.
As a follow up on my own question. This is what the docs say:
A
I really appreciate your input Leon.
On Wed, 2009-01-28 at 11:07 +0100, Leon Rosenberg wrote:
> > "RMI TCP Connection(42)-173.x.x.x" - Thread t...@112
> > java.lang.Thread.State: RUNNABLE
>
> reading from socket, usually not a problem.
>
I thought so. Thanks.
> > "http-8081-35" - Thread t...
On Wed, Jan 28, 2009 at 10:42 AM, Pieter Temmerman
wrote:
>
>
>>Have you found any java.lang.Thread.State: RUNNABLE threads? They are
>>usually more interesting if it comes to a high cpu :-)
>
> These are the RUNNABLE threads on Tomcat 6:
>
> "RMI TCP Connection(42)-173.x.x.x" - Thread t...@112
>
Thanks to all for your helpful input.
As a result of trying to reproduce the problem on pre-production
servers, I used JMeter to generate some load.
Let me give some more specific information about the setup.
I have two Tomcat servers:
- Tomcat 5.5.7 (jdk 1.5.0_09) (I know, it's old. But this i
> From: Pieter Temmerman [mailto:ptemmerman@sadiel.es]
> Subject: Thread dump analysis
>
> Memory usage looks healthy, but CPU usage goes sky high (mainly caused
> by the Java Tomcat process).
If you're truly out of memory, the GC thread(s) may be running almost
continuously. However, with m
Have you found any java.lang.Thread.State: RUNNABLE threads? They are
usually more interesting if it comes to a high cpu :-)
Also, as David posted, what is the HEAP usage? it's usually at the end
of the dump.
regards
Leon
On Mon, Jan 26, 2009 at 5:37 PM, Pieter Temmerman
wrote:
> Hi all.
>
> I'
We spent weeks looking at similar bizarre thread stack dumps.
Eventually it turned out to be a GC problem. The JVM will all
of a sudden decide to stop large numbers of threads from running
(or perhaps it stops one, but that thread happens to be holding
a heavily contended lock --- database connect
29 matches
Mail list logo
