g.Thread.State: BLOCKED
> at com..service.DHTMLService.getJSData(Unknown Source)
> - waiting to lock <751833aa> (a com..service.DHTMLService)
> owned by
> "Thread-678" t@751
> [ ]
>
> . . . same waiting to lock state for all BLOCKED threads
lt;751833aa> (a com..service.DHTMLService) owned
by
"Thread-678" t@751
[ ]
. . . same waiting to lock state for all BLOCKED threads
NOTE:
These are intentional replacements substituting for actual values
--
View this message in context:
http://tomcat.10.x6.nabble.com/
o OAuth from the OP's question.
As per http://markmail.org/message/mukjphyw7kganuqi and
http://markmail.org/message/7x2tjic2azwfbw5o an unsubscription will follow.
Mark
>
>
>> Date: Fri, 2 May 2014 15:22:01 -0700
>> From: rallav...@gmail.com
>> To: users@tomcat.apach
gt;> at java.lang.Thread.run(Thread.java:744)
>
> Looks like this is waiting to log something. Where are you writing your
> logs? Is it a local disk or network disk? Is the disk busy or otherwise
> slow?
>
> Dan
>
>>
>> Locked ownable synchronizers:
>> - <0x0007e
oolExecutor$Worker)
>
> On 5/2/14, 9:19 PM, Christopher Schultz wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Rallavagu,
>>
>> On 5/2/14, 6:22 PM, Rallavagu wrote:
>>> Tomcat Version: 7.0.
HA256
Rallavagu,
On 5/2/14, 6:22 PM, Rallavagu wrote:
Tomcat Version: 7.0.47 JVM Version: 1.7.0_51-b13
I see many blocked threads (90) in the thread dump. There are
mainly two monitors that block 69 threads.
One of them is below. It appears tha
1247)
at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101)
On 5/2/14, 9:19 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Rallavagu,
On 5/2/14, 6:22 PM, Rallavagu wrote:
Tomcat Version: 7.0.47 JVM Version: 1.7.0_51-b13
I see many blocked threads (90) in the thread
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Rallavagu,
On 5/2/14, 6:22 PM, Rallavagu wrote:
> Tomcat Version: 7.0.47 JVM Version: 1.7.0_51-b13
>
> I see many blocked threads (90) in the thread dump. There are
> mainly two monitors that block 69 threads.
>
> One of them is
-security-oauth.codehaus.org/oauth1.html#Managing_Provider_Tokens
Martin
> Date: Fri, 2 May 2014 15:22:01 -0700
> From: rallav...@gmail.com
> To: users@tomcat.apache.org
> Subject: BLOCKED threads
>
> All,
>
> Tomcat Version: 7.0.47
> JVM Version: 1.7.0_51-b13
>
&g
All,
Tomcat Version: 7.0.47
JVM Version: 1.7.0_51-b13
I see many blocked threads (90) in the thread dump. There are mainly two
monitors that block 69 threads.
One of them is below. It appears that it is simply trying to log
/2011 10:05 AM, Violeta Georgieva wrote:
Hi,
I am using Tomcat 6.0.29 and SUN JVM.
I experience high memory consumption caused by BLOCKED Threads.
I would appreciate any help or suggestion how to solve the problem.
I can see the following in the thread dump:
"http-8080-73" daemon p
Thanks to all of you!
I'm profiling the application now.
Happy New Year
Violeta
2011/12/23 Christopher Schultz
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Rainer,
>
> On 12/22/11 2:00 PM, Rainer Jung wrote:
> > Hmmm, actually I had a short look at the code of
> >
> > sun.util.resourc
> From: Rainer Jung [mailto:rainer.j...@kippdata.de]
> Subject: Re: High memory consumption caused by BLOCKED Threads
> Hmmm, actually I had a short look at the code of
> sun.util.resources.TimeZoneNames.getContents(TimeZoneNames.java:185)
> and i don't unerstand why it is w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rainer,
On 12/22/11 2:00 PM, Rainer Jung wrote:
> Hmmm, actually I had a short look at the code of
>
> sun.util.resources.TimeZoneNames.getContents(TimeZoneNames.java:185)
>
> and i don't unerstand why it is waiting for a monitor entry. The
> method
Chuck,
On 22.12.2011 14:07, Caldarale, Charles R wrote:
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: High memory consumption caused by BLOCKED Threads
Fix your app so that it releases the locks (probably synchronized
sections) on the SimpleDateFormat objects.
Read the
> From: David kerber [mailto:dcker...@verizon.net]
> Subject: Re: High memory consumption caused by BLOCKED Threads
> Fix your app so that it releases the locks (probably synchronized
> sections) on the SimpleDateFormat objects.
Read the stack trace more carefully - only Tomcat or
t;
>> I am using Tomcat 6.0.29 and SUN JVM.
>> I experience high memory consumption caused by BLOCKED Threads.
>>
>> I would appreciate any help or suggestion how to solve the problem.
>>
>
> Fix your app so that it releases the locks (probably synchronized
On 12/22/2011 4:05 AM, Violeta Georgieva wrote:
Hi,
I am using Tomcat 6.0.29 and SUN JVM.
I experience high memory consumption caused by BLOCKED Threads.
I would appreciate any help or suggestion how to solve the problem.
Fix your app so that it releases the locks (probably synchronized
The blocked threads that are waiting to get the lock, in order to finish
the response, are holding a lot of memory that they cannot release.
I have >50 blocked threads that are waiting.
2011/12/22 Mark Thomas
> On 22/12/2011 09:05, Violeta Georgieva wrote:
> > Hi,
> >
>
On 22/12/2011 09:05, Violeta Georgieva wrote:
> Hi,
>
> I am using Tomcat 6.0.29 and SUN JVM.
> I experience high memory consumption caused by BLOCKED Threads.
Blocked threads will not cause high memory consumption.
> I would appreciate any help or suggestion how to solve th
Hi,
I am using Tomcat 6.0.29 and SUN JVM.
I experience high memory consumption caused by BLOCKED Threads.
I would appreciate any help or suggestion how to solve the problem.
I can see the following in the thread dump:
"http-8080-73" daemon prio=10 tid=0x7ff9a4586000 nid=0x7d3 w
tion stays outside of the
> pool for to long. In some cases this is adequate.
>
>
Thanks a lot for your help, I'm going to read up about that !
Raphael
--
View this message in context:
http://www.nabble.com/Blocked-threads-in-Tomcat-web-app-tp2445768
On 13.07.2009 11:31, Raphael Neve wrote:
>
> Rainer Jung-3 wrote:
>>
>> [...]
>>
>> Yup, and the code run by the finalizer makes a network call (likely to
>> the database), which seems to be a very bad pattern. Finalizers are not
>> a great idea by themselves, but one needs to keep them as simple
aphael
--
View this message in context:
http://www.nabble.com/Blocked-threads-in-Tomcat-web-app-tp24457682p24458570.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubs
On 13.07.2009 11:05, Raphael Neve wrote:
>
> Rainer Jung-3 wrote:
>> TP-Processor16 owns lock at 0x73a71c40 and thus blocks TP12, TP5 and TP1.
>>
>> TP16 and TP2 both wait for lock 0x73a71dd0. The thread holding this lock
>> is not in your dump.
>>
>> Since the lock is of type
>> org.firebirdsql.g
, is that right ? The next question of course is : what is
making the finalizer keep that lock ?
Thanks for your insight,
Raphael
http://www.nabble.com/file/p24458247/thread%2Bdump.txt thread+dump.txt
--
View this message in context:
http://www.n
On 13.07.2009 10:12, Raphael Neve wrote:
> Hello all,
>
> I have a problem with a web application using Tomcat 5.5.27 under Fedora
> Linux and database Firebird 2.1.
>
> The application runs fine for a day or so, then I begin getting blocked
> threads. Eventually, the he
Hello all,
I have a problem with a web application using Tomcat 5.5.27 under Fedora
Linux and database Firebird 2.1.
The application runs fine for a day or so, then I begin getting blocked
threads. Eventually, the heap space runs out and the application grinds to a
halt.
I realise this may
On Fri, Oct 31, 2008 at 5:52 PM, Caldarale, Charles R
<[EMAIL PROTECTED]> wrote:
>> From: emerson cargnin [mailto:[EMAIL PROTECTED]
>> Subject: Blocked threads in tomcat
>>
>> Below is the JConsole result, you can see that there are a lot of
>> blocked
> From: emerson cargnin [mailto:[EMAIL PROTECTED]
> Subject: Blocked threads in tomcat
>
> Below is the JConsole result, you can see that there are a lot of
> blocked threads on there.
>
> Stack trace:
> java.lang.O
is the JConsole result, you can see that there are a lot of
blocked threads on there.
Name: http-18081-Processor95
State: WAITING on
[EMAIL PROTECTED]
Total blocked: 106 Total waited: 129
Stack trace:
java.lang.Object.wait(Native Method
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark,
Mark Thomas wrote:
> Sounds like you have a connection leak. There are various techniques for
> tracking these down. One I like is setting the connection pool size to 1 in
> your dev environment and then running your tests.
+1
I always use a
Darren Kukulka wrote:
> Hi,
>
>
>
> We've got a Tomcat 6.0.13 server running a single application under
> 64-bit windows with 64-bit SUN JDK 1.6_03
>
>
>
> It runs into situations where a large number of blocked threads appear
> that seem to relate t
Hi,
We've got a Tomcat 6.0.13 server running a single application under
64-bit windows with 64-bit SUN JDK 1.6_03
It runs into situations where a large number of blocked threads appear
that seem to relate to hibernate functions unable to obtain database
connections/resources. This
Pascal,
Our connectionTimeout value is set to the Tomcat default of 6 (60
seconds). I'm not exactly sure how to determine if that's too high?
Any ideas? Also, we're around 30-40 concurrent users during our peak
times of day but that's about it. The server load is OK... I mean right
no
Check your connectiontimeout value. May be it is too high ?
Have you a heavy load on this server ? How many (concurent) users ?
On 10/18/06, Derek Wormdahl <[EMAIL PROTECTED]> wrote:
We initially started this project running on the Sun JVM but ran into an
issue with the JVM aborting when doing a
EMAIL PROTECTED]
Subject: max_threads issue & blocked threads (*warning* long
thread dump attached)
We've been investigating an issue with a web application
that is causing us problems. We are seeing the Tomcat
server running out of available threads after a few hours
of operation.
> From: Derek Wormdahl [mailto:[EMAIL PROTECTED]
> Subject: max_threads issue & blocked threads (*warning* long
> thread dump attached)
>
> We've been investigating an issue with a web application
> that is causing us problems. We are seeing the Tomcat
> s
38 matches
Mail list logo