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.
)
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 dump
(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Locked ownable synchronizers:
- 0x0007e1b0f8d0 (a
java.util.concurrent.ThreadPoolExecutor$Worker)
On 5/2/14, 9:19 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Rallavagu,
On 5/2/14, 6:22
Logs are written to local disk. Don't have data on disk stats. Thanks.
On May 5, 2014, at 7:19 AM, Daniel Mikusa dmik...@gopivotal.com wrote:
On May 3, 2014, at 9:08 PM, Rallavagu rallav...@gmail.com wrote:
Here is the thread BLOCKED waiting on another lock.
http-bio-28080-exec-613
This usually means that "client" has disconnected before the request
could be completed. Generally, this might happen when a user navigates
away from a web page before it is completely rendered. You might want to
gather more information to understand this better.
On 10/26/15 7:15 AM, Yogesh
Tomcat 7.0.14
Looking into a thread dump (after tomcat stopped accepting connections)
http-bio-8080-acceptor is missing while http-bio-8080-AsyncTimeout
thread is present.
The application is deployed to a non root context while ROOT is served
by tomcat's default ROOT app.
What could have
Please take a look at Memory Analyzer tool
(http://www.eclipse.org/mat/). Run the app and take the heap dump while
app is running and use the tool to analyze it. You could use VisualVM
with plugins to get instrumentation or you could use hprof
I have this long running thread. It appears to be reading but the stack
trace does not give much of a clue. Could anyone help with where to
start? Thanks.
"tomcat-exec-2655" daemon prio=10 tid=0x7fc459061000 nid=0x6a58
runnable [0x7fc4a67e6000]
java.lang.Thread.State: RUNNABLE
Also, it could be keep-alive for client connection as well. In any case,
how long a keep-alive connection will be in this state by default? Thanks.
On 1/19/16 2:24 PM, Rallavagu wrote:
Thanks Mark. It seems to be running for almost 10 seconds and there is a
Load Balancer between
Thanks Mark. It seems to be running for almost 10 seconds and there is a
Load Balancer between. Is it a suspect?
On 1/19/16 2:09 PM, Mark Thomas wrote:
On 19/01/2016 21:42, Rallavagu wrote:
I have this long running thread. It appears to be reading but the stack
trace does not give much
I have this long running thread. It appears to be reading but the stack
trace does not give much of a clue. Could anyone help with where to
start? Thanks.
Tomcat 7.0.42 with JDK 7
"tomcat-exec-2655" daemon prio=10 tid=0x7fc459061000 nid=0x6a58
runnable [0x7fc4a67e6000]
On 1/21/16 4:13 AM, Christopher Schultz wrote:
Rallavagu,
On 1/19/16 6:14 PM, Rallavagu wrote:
On 1/19/16 2:43 PM, Mark Thomas wrote:
On 19/01/2016 22:36, Rallavagu wrote:
Also, it could be keep-alive for client connection as well. In any case,
how long a keep-alive connection
On 1/19/16 2:43 PM, Mark Thomas wrote:
On 19/01/2016 22:36, Rallavagu wrote:
Also, it could be keep-alive for client connection as well. In any case,
how long a keep-alive connection will be in this state by default? Thanks.
This behaviour is entirely normal. Why are you concerned about
All,
From a thread dump and corresponding "top" output it is reported that
the following thread is consuming significant CPU (around 80%)
"http-bio-28080-exec-437" daemon prio=10 tid=0x7f4acc0de000
nid=0x54ce waiting on condition [0x7f4b038f7000]
java.lang.Thread.State:
On 3/10/16 1:02 PM, Konstantin Kolinko wrote:
2016-03-10 22:54 GMT+03:00 Christopher Schultz <ch...@christopherschultz.net>:
Rallavagu,
On 3/10/16 2:11 PM, Rallavagu wrote:
From a thread dump and corresponding "top" output it is reported
that the following thread is consu
On 3/10/16 11:54 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rallavagu,
On 3/10/16 2:11 PM, Rallavagu wrote:
From a thread dump and corresponding "top" output it is reported
that the following thread is consuming significant CPU (around
80%)
On 3/10/16 2:09 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rallavagu,
On 3/10/16 4:02 PM, Rallavagu wrote:
On 3/10/16 11:54 AM, Christopher Schultz wrote:
Are you sure you have matched-up the correct thread within the
JVM that is using all that CPU?
How
On 3/10/16 5:23 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rallavagu,
On 3/10/16 8:10 PM, Rallavagu wrote:
On 3/10/16 2:33 PM, Christopher Schultz wrote: Rallavagu,
On 3/10/16 5:16 PM, Rallavagu wrote:
On 3/10/16 2:09 PM, Christopher Schultz wrote
On 3/30/16 9:55 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rallavagu,
On 3/30/16 11:54 AM, Rallavagu wrote:
Tomcat 7.0.47, JDK 7
I have following long running socketwrite thread (more than 10
sec). Wondering what could cause this so I can further look
On 3/30/16 10:25 AM, Rallavagu wrote:
On 3/30/16 9:55 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rallavagu,
On 3/30/16 11:54 AM, Rallavagu wrote:
Tomcat 7.0.47, JDK 7
I have following long running socketwrite thread (more than 10
sec). Wondering what
Tomcat 7.0.47, JDK 7
When an app is hot deployed in-place by simply copying the .war file
into webapps directory, the old webappclassloader is not cleared
completely because of inefficient context shutdown from the app. In this
case, two instances of WebAppClassLoader are running for the same
instance be active?
On 4/4/16 8:03 PM, Christopher Schultz wrote:
Rallavagu,
On 4/4/16 8:13 PM, Rallavagu wrote:
Tomcat 7.0.47, JDK 7
When an app is hot deployed in-place by simply copying the .war file
into webapps directory, the old webappclassloader is not cleared
completely because
Tomcat 7.0.47, JDK 7
I have following long running socketwrite thread (more than 10 sec).
Wondering what could cause this so I can further look and investigate.
"http-bio-28080-exec-1497" daemon prio=10 tid=0x7f812c230800
nid=0x72fa runnable [0x7f80010f9000]
Tomcat 7.0.47 running on Linux
I have started investigating after noticing following messages from
"dmesg" output on a production server.
"possible SYN flooding on port 28080. Sending cookies."
Started looking into this as the connections to this server are timing
out (Connect Timeout
One thing I would check is if it is Tomcat that is sending it or an
intermediary load balancer.
On 8/31/16 8:50 AM, john.e.gr...@wellsfargo.com wrote:
All,
I'm using Tomcat 7.0.70 and am having trouble understanding why Tomcat is sending "Connection:
close" in the response header as often as
Tomcat 7.0.70, JDK 1.7.0_80
$java -version
java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
There are many threads BLOCKED as below and due to this these threads
are very slow. Anybody else experienced
All,
Tomcat 7.0.70 with bio connector
I have been monitoring JMX for "currentThreadCount" and
"currentThreadsBusy". If I understand correctly, currentThreadCount
would not exceed "maxThreads" configuration and "currentThreadsBusy"
apparently shows "busy" threads at that time. I am wondering
Here is the configuration snippet.
As you can see, _not_ using executor. Thanks.
On 10/31/16 11:58 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Rallavagu,
On 10/31/16 1:59 PM, Rallavagu wrote:
All,
Tomcat 7.0.70 with bio connector
I
On 10/31/16 12:44 PM, Mark Thomas wrote:
On 31/10/2016 19:38, Rallavagu wrote:
Here is the configuration snippet.
As you can see, _not_ using executor. Thanks.
When using the internal thread pool, that delay is hard-coded to 60s. If
you want to configure it, use
As per https://tomcat.apache.org/tomcat-7.0-doc/config/executor.html it
appears "maxIdleTime" could be what I am looking for. Is there a
corresponding config parameter for internal thread pool?
On 10/31/16 12:44 PM, Mark Thomas wrote:
On 31/10/2016 19:38, Rallavagu wr
On 10/31/16 12:54 PM, Mark Thomas wrote:
On 31/10/2016 19:52, Rallavagu wrote:
As per https://tomcat.apache.org/tomcat-7.0-doc/config/executor.html it
appears "maxIdleTime" could be what I am looking for. Is there a
corresponding config parameter for internal thread pool?
Tomcat 7.0.70 - Sun JDK 1.7.0_80
I have following long running thread (almost 5 sec). It appears to be
reading data from socket (external resource potentially). Wonder how I
could go about debug these kind of threads to understand which external
resource is it spending more time on reading.
On 10/14/16 1:01 AM, Mark Thomas wrote:
On 12/10/2016 16:22, Rallavagu wrote:
Tomcat 7.0.70 - Sun JDK 1.7.0_80
I have following long running thread (almost 5 sec).
No you don't. That thread isn't doing it any work. It is blocking,
waiting for I/O.
Well, I got in impression because
33 matches
Mail list logo
