JVM threads BLOCKED

Hi,
One of our java application stopped responding. In the thread dump it is observed that JVM threads like "GC Daemon", "Low Memory Detector" etc are found to be in BLOCKED state. Also our application threads got blocked. I really wonder why JMV threads got blocked. Can anyone share your experience with such problems and how to overcome it. Environment details and Thread dump part can be found below
OS: RHEL 5.4
Java(TM) SE Runtime Environment (build 1.6.0_34-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.9-b04, mixed mode)
Thread 15910 "RMI Scheduler(0)": (state = BLOCKED)
     at sun.misc.Unsafe.park(Native Method)
     at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:196)
     at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2025)
     at java.util.concurrent.DelayQueue.take(DelayQueue.java:164)
     at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:609)
     at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:602)
     at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
     at java.lang.Thread.run(Thread.java:662)
Thread 15907 "GC Daemon": (state = BLOCKED)
     at java.lang.Object.wait(Native Method)
     - waiting on <0x00000000f041e790> (a sun.misc.GC$LatencyLock)
     at sun.misc.GC$Daemon.run(GC.java:100)
     - locked <0x00000000f041e790> (a sun.misc.GC$LatencyLock)
Thread 15906 "RMI RenewClean-[10.36.107.139:49198]": (state = BLOCKED)
     at java.lang.Object.wait(Native Method)
     - waiting on <0x00000000f041e710> (a java.lang.ref.ReferenceQueue$Lock)
     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
     - locked <0x00000000f041e710> (a java.lang.ref.ReferenceQueue$Lock)
     at sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:516)
     at java.lang.Thread.run(Thread.java:662)
VM Thread 15809 "Low Memory Detector": (state = BLOCKED)
VM Thread 15808 "C2 CompilerThread1": (state = BLOCKED)
VM Thread 15807 "C2 CompilerThread0": (state = BLOCKED)
Thread 15806 "Signal Dispatcher": (state = BLOCKED)
Thread 15805 "Finalizer": (state = BLOCKED)
     at java.lang.Object.wait(Native Method)
     - waiting on <0x00000000f0075510> (a java.lang.ref.ReferenceQueue$Lock)
     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
     - locked <0x00000000f0075510> (a java.lang.ref.ReferenceQueue$Lock)
     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
     at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
Thread 15804 "Reference Handler": (state = BLOCKED)
     at java.lang.Object.wait(Native Method)
     - waiting on <0x00000000f0075540> (a java.lang.ref.Reference$Lock)
     at java.lang.Object.wait(Object.java:485)
     at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
     - locked <0x00000000f0075540> (a java.lang.ref.Reference$Lock)
Thread 15798 "main": (state = IN_NATIVE)

What causes these threads get BLOCKED? Can application can influence these threads get BLOCKED? What I am supposed to do now?

Similar Messages

Thread blocking on java.nio.charset.CoderResult

Hello all,
I have a multi-threaded app which does some fairly intestive string operations (basically extracts text from documents for indexing a search system).
I am seeing a massive bottleneck around the java.nio.charset.CoderResult class. When profiling, I see a whole stack of threads blocking on (waiting for) a monitor on this java.nio.charset.CoderResult class. Seems to be a result of string encoding/decoding (I am often encoding strings as UTF-8).
Anyone know why the JVM would want my threads to sync on this class? It's creating a huge performance issue for my app. Approximately 15% of ALL the processing time is spent waiting for this class.
Help!

I would guess that you're using some of the static methods in the CoderResult class. The static methods CoderResult.unmappableCache(), CoderResult.malformedForLength() and CoderResult.malformedCache all use a static inner class called Cache. Its get() method is synchronized on Cache.class. Since the Cache inner-class is static, any part of your multi-threaded application that goes through the Cache.get() method is going to be waiting for the lock on Cache.class.
Could you create a CoderResult instance for each thread? That would mean that there would be a different static Cache class for each thread, reducing the number of threads competing for the Cache.class lock.
I'd have to see some of your code to give a better answer.
Brian

Client threads block forever in SSLSocketImpl.startHandshake

Hi --
We have an application which has 4 threads polling a webservice over HTTPS every 1-2 minutes. We don't control the server platform or webservice framework.
We've encountered a problem where one by one the threads stop polling. This has occurred 3 times, every time over a weekend (the busiest time for our polling). Each thread "freezes" at a different time; all 4 threads are "frozen" after about 24 hours.
JVM thread dumps suggests that the polling threads are blocked inside SSLSocketImpl.startHandshake; each one always has the same stacktrace within the JSSE & Axis libraries:
"SOAP Client Thread: Footy Feed" prio=5 tid=0x2877D388 nid=0x518 runnable [2c3af000..2c3afd8c]
     at java.net.SocketInputStream.socketRead0(Native Method)
     at java.net.SocketInputStream.read(SocketInputStream.java:129)
     at com.sun.net.ssl.internal.ssl.InputRecord.a(DashoA6275)
     at com.sun.net.ssl.internal.ssl.InputRecord.read(DashoA6275)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
     - locked <0A931078> (a java.lang.Object)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
     - locked <0A931068> (a java.lang.Object)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA6275)
     at org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFactory.java:186)
     at org.apache.axis.transport.http.HTTPSender.getSocket(HTTPSender.java:131)
     at org.apache.axis.transport.http.HTTPSender.writeToSocket(HTTPSender.java:370)
     at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:88)
     at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
     at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
     at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
     at org.apache.axis.client.AxisClient.invoke(AxisClient.java:147)
     at org.apache.axis.client.Call.invokeEngine(Call.java:2719)
     at org.apache.axis.client.Call.invoke(Call.java:2702)
     at org.apache.axis.client.Call.invoke(Call.java:2378)
     at org.apache.axis.client.Call.invoke(Call.java:2301)
     at org.apache.axis.client.Call.invoke(Call.java:1758)
...(our application stacktrace)...
Client: JDK1.4.1-b21, JBoss 3.2.7RC1, Axis 1.2RC2, Win2k Server SP4, no client certificates
Server: Apache 1.3.29 (Unix) mod_ssl 2.8.16 OpenSSL 0.9.6j, mod_jk to Tomcat.
There's at least one firewall between client and server.
This problem appears similar: <http://issues.apache.org/bugzilla/show_bug.cgi?id=31832> & I've emailed the author.
I've googled a lot of forums for a solution without success.
Any help gratefully received.
Thanks
-- Richard Barnett

Thanks for the reply.
This case is different from that JMeter bug report as it's a SOAP request.
We're not explicitly setting a timeout, but Axis defaults to a 10 minute timeout on its requests. The source seems to indicate that this doesn't apply when creating SSL sockets (although it is used when creating regular sockets). No timeout occurs in any case.
-- Richard

Thread blocked in printStackTrace

I find one of my thread blocked in printStackTrace after perform an overload test. But it doesn't wait any java lock. So I don't know what happened.
Part of dumped thread stack looked like this:
"Thread: 553" daemon prio=5 tid=0x00598f68 nid=0x23f runnable [95d7f000..95d7fc28]
     at java.lang.Throwable.getStackTraceElement(Native Method)
     at java.lang.Throwable.getOurStackTrace(Throwable.java:591)
     - locked <0xc423b3a8> (a java.lang.Throwable)
     at java.lang.Throwable.printStackTrace(Throwable.java:510)
My application runs on solaris, sparc machine. JVM is 1.4.2_04-b05.

Can u pstack the process at this moment? The stacks of all the threads are probably too large to be shown here.
Show the thread #575. i.e. nid = 0x23f, convert to decimal = 575, maybe its stuck in the native portion.
Hope this helps.

How to find out the JVM thread that is consuming high CPU

I am using WL 10.3, JRockit JVM on Linux. I have taken thread dumps. How to find out the JVM thread that is consuming high CPU?
I know how to map it Sun JVM on Solaris. I haven't done in on JRockit so far. Please advise.

Check out some of Marcus Hirt's blog entries for details about how to use JRockit Mission Control. It's a very nice tool that should provide a lot of insight:
http://blogs.oracle.com/hirt/

Thread Problem - (Thread Blocking Problems?)

Hi Friends
In my program while using thread i found a problem in this code .
In this whlie running the 'msg' was printen only after all 5 inputs are given .
why i was not getting output after one input.why the thread out was waiting for remaining threads input.
my code is
import java.io.*;
class MyThread extends Thread
BufferedReader bin;
   MyThread()
     super();
     start();
   public void run()
      try
       bin=new BufferedReader(new InputStreamReader(System.in));
       String msg=bin.readLine();
       System.out.println(msg);
      catch(IOException e)
         System.out.println(e);
public class Threads
     public static void main(String args[])
          for(int i=0;i<5;i++)
            new MyThread();
}

Hi Friends
In my program while using thread i found a problem
em in this code .
In this whlie running the 'msg' was printen only
after all 5 inputs are given .
why i was not getting output after one input.why
hy the thread out was waiting for remaining threads
input.Probably because of how the scheduler was rotating among the threads while waiting for input and queueing up output.
When you call readLine, that thread blocks until a line is available. So it probably goes to the next thread's readLine, and so on. All threads are probably blocked waiting for input before you enter a single character.
Something inside the VM has to coordinate the interaction with the console, and between that and your threads, the out stuff just doesn't get a chance to display right away.
In general, you can't predict the order of execution of separate threads.

[svn:bz-trunk] 12951: Changed synchronized PropertyProxyRegistry#getRegistry method to non-synchronized to avoid threads blocking in message push .

Revision: 12951
Revision: 12951
Author:   [email protected]
Date:     2009-12-15 02:17:31 -0800 (Tue, 15 Dec 2009)
Log Message:
Changed synchronized PropertyProxyRegistry#getRegistry method to non-synchronized to avoid threads blocking in message push.
Checkintests: Pass with the usual 3-4 tests that time out with and without this change.
QA: Yes
Doc: No
Modified Paths:
    blazeds/trunk/modules/core/src/flex/messaging/io/PropertyProxyRegistry.java

Revision: 12951
Revision: 12951
Author:   [email protected]
Date:     2009-12-15 02:17:31 -0800 (Tue, 15 Dec 2009)
Log Message:
Changed synchronized PropertyProxyRegistry#getRegistry method to non-synchronized to avoid threads blocking in message push.
Checkintests: Pass with the usual 3-4 tests that time out with and without this change.
QA: Yes
Doc: No
Modified Paths:
    blazeds/trunk/modules/core/src/flex/messaging/io/PropertyProxyRegistry.java

Weblogic 10 jsp compliation thread block problem

hi
i am using weblogic 10 and jdk1.5.
My application is deployed in ear format, with 2 wars, and 20 ejbs.
The ear works ok with weblogic 8.1.
In the application , one war passes the request to another war, that's the workflow....
Now when the request is passed on the second war, a jsp is supposed to open....but the application get stuck there.
The call is like this in a servlet....
     reqDisp = req.getRequestDispatcher("/newIndex.jsp");
reqDisp.forward(req, res);
The new index jsp is not opened....there is no problem with it it comiples ok....i check with weblogic appc...and it is working on weblogic 8.1.
when i stop the server...the log gives me following exception info.
"ExecuteThread: '12' for queue: 'default'" daemon prio=6 tid=0x2b8edad0 nid=0xc1
0 in Object.wait() [0x2da1e000..0x2da1fb64]
at java.lang.Object.wait(Native Method)
- waiting on <0x07f94608> (a javelin.client.JobWaiter)
at java.lang.Object.wait(Object.java:474)
at javelin.client.JobWaiter.blockUntilFinished(JobWaiter.java:45)
- locked <0x07f94608> (a javelin.client.JobWaiter)
at javelin.client.ClientUtilsImpl.build(ClientUtilsImpl.java:838)
at weblogic.servlet.jsp.JavelinxJSPStub.compilePage(JavelinxJSPStub.java:248)
at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:200)
at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:164)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:235)
- locked <0x07ef8220> (a weblogic.servlet.jsp.JavelinxJSPStub)
at weblogic.servlet.internal.ServletStubImpl.onAddToMapException(ServletStubImpl.java:391)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:309)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:503)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:245)
at LCDisplayController.handleProcessing(Unknown Source)
at DisplayControllerServlet.doPost(Unknown Source)
at DisplayControllerServlet.doGet(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:503)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:245)
at com.orbitech.workflow.servlet.WFAppListController.openWorkitem(WFAppListController.java:793)
at com.orbitech.workflow.servlet.WFAppListController.processRequest(WFAppListController.java:102)
at com.orbitech.workflow.servlet.WFAppController.doProcessRequest(WFAppController.java:97)
at com.orbitech.workflow.servlet.WFAppController.doGet(WFAppController.java:64) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
i think the there is thread blocking and the jsp is not getting compiled or smthing....
i am unable to understnd the exception....
any help, suggestion ? thanks in advance.

We are using jBPM and Hibernate in our application which runs fine on other java application servers. On Weblogic we were getting an error:
org.hibernate.HibernateException: Errors in named queries: GraphSession...........
By adding:
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
to our weblogic.xml, Weblogic used our Hibernate3 and antl-2.7.6 .jar files which resolved this issue but created multiple CompilationException errors in many .jsp's. (as follows)
Error 500--Internal Server Error
weblogic.servlet.jsp.CompilationException: Failed to compile JSP /WEB-INF/jsp/struts/dashboards/portfolio_chart.jsp
portfolio_chart.jsp:1:1: The validator class: "org.apache.taglibs.standard.tlv.JstlCoreTLV" has failed with the following exception: "java.lang.ClassCastException: weblogic.xml.jaxp.RegistrySAXParserFactory".
<%@ taglib uri="/jstl-core" prefix="c" %>
^---------------------------------------^
portfolio_chart.jsp:1:1: The validator class: "com.primavera.pvweb.taglib.JSMessageTagLibraryValidator" has failed with the following exception: "java.lang.ClassCastException: weblogic.xml.jaxp.RegistrySAXParserFactory".
<%@ taglib uri="/jstl-core" prefix="c" %>
^---------------------------------------^
     at weblogic.servlet.jsp.JavelinxJSPStub.compilePage(JavelinxJSPStub.java:298)
     at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:216)
     at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:165)
     at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:235)
     at weblogic.servlet.internal.ServletStubImpl.onAddToMapException(ServletStubImpl.java:394)
     at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:309)
Is this a Weblogic bug ?

Thread Blocked Problem

I Have a multithread application which:
- access to database
- write files
- read files
- execute external process using exec
What considerations should I take in order to avoid Threads Blocking? When Thread blocking occurs how can I know what is the cause?
Thanks!
T

http://www.ibm.com/developerworks/library/j-thread.html
- Saish

JVM Thread Dump

Hello, I am using JES 2003Q4. I would like to be able to obtain a jvm thread dump on the portal server. However when I issue a kill -3 to any of the webservd processes, the web server simply shuts down. No thread dump is observed in the error log. I am not using the -Xrs option in my server.xml file. Is there any way to force a thread dump? Doing so without stopping the web server would be preferable but not absolutely necessary.
Thanks!

Well you could try debug and verbose. I've got a feeling that on windows you only see the parent process in the thread dump. Is it possible for you to try this on a 'nix platform? You might get more information.

Why happens when threads block on I/O?

I want to know what are the reasons for threads blocking on I/O.Do they block to allow the I/O operation or do they block(enter in waiting state) to allow other threads to continue operation while I/O opeation ?
If a particular thread is blocked for I/O do other threads get a chance by the Thread Scheduler ?
If this question has been asked and answered somewhere ,kindly let me know so that i can follow that thread.
Thanks for your consideration.

>
Which thread is that which is "suspended"? The thread which is blocked waiting for the I/O will, um, wait for the I/O. That means it doesn't do anything else. It just waits. That's all. Is that not obvious?
The "suspended" one is the one which is blocked waiting for the I/O.My question is when say the I/O is complete or the stream closes,won't the thread start executing again if given a chance by the scheduler ?
Of course that doesn't affect any other threads. And what do you mean by "related to this thread"? There's no such concept. Each thread operates independently, except when they interact by holding locks or waiting for locks.
"Related to this thread" means thread that share some common resources or say locks.Here i meant any other thread than the one which is blocked for I/O.
Seems to me your mental model of threads is far too complicated. You need to get rid of all those imaginary concepts you're trying to insert there.That is what i am trying to simplify !!!!

How jvm threads works on new Linux 2.6 scheduler with SMP kernell

Hi,
i'm using Sun JDK Java HotSpot(TM) Server VM (build 1.5.0_14-b03, mixed mode) to run tomcat,
anyone knows How JVM threads works on new Linux 2.6 scheduler with SMP kernel?
i ask this, because in a single processor machine the tomcat replies more fast than a dual processor machine, maybe the reason is, that SMP load balancing made for new scheduler, slow down the JVM performance for threads? there is a way to avoid this?
reference about Linux Scheduler: http://www-128.ibm.com/developerworks/linux/library/l-scheduler/?ca=dgr-lnxw09LinuxScheduler
bug that have "same" problem: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5038858
thanks for any insight

This is bug:
6328462 Linux getCurrentThreadCpuTime() does not match with getThreadCpuTime(currentThread)
It will be fixed in:
- JDK 6.0 (Mustang) build b63
- JDK 1.5.0_07 build b01
The problem is that the HotSpot VM takes the stat info from the file'/proc/$tid/stat'
which is incorrect on Linux kernels 2.6+ with NPTL because this file aggregates
per-process (.vs. per-thread) usage on these kernels.
The file '/proc/self/task/$tid/stat' still has the per-thread usage and must be used instead.
There is also a performance bug:
6200022: JVMTI GetCurrentThreadCpuTime slow on Linux
This bug is about using new Linux posix compliant process clocks (2.6.10) :
http://sources.redhat.com/ml/libc-alpha/2004-10/msg00117.html
It is too late to fix this in Mustang but can be possible in one of the update releases.
Thank you for posting the question!
Serguei

Thread Blocking..help

Hi All,
I'm finding it hard to understand the concept of Threads blocking, for example, when u have a UI u'll want to run your main work in a different thread than in the event dispatcher thread as that will speed things up with the GUI.
now let's say we have the following code:
//Thread to prevent blocking and return control to GUI
Runnable r = new Runnable() {
public void run() {
try
ThreadThatDoesAlotOfWork.start();
} catch (Exception e)
e.printStackTrace();
if I'll run it within a another thread within the GUI, howcome it doesn't block till all work is done?
could u provide some code for blocking/non blocking threads..
can u direct me maybe to helpfull docs somewhere..
Thanks for the help and hope I'm being clear with my question..

That article is about synchronisation access to variables by mutiple threads.
I'm talking about using Threads for speeding things up...
Thanks for the reply anyway..

Java JVM outof memory - Thread blocks..

Hi,
I am running web application on Apache/tomcat with MySQL5.0.46 database. Application server running witout any problem for 2 days and having around 100 threads. One of my threads throws OutOfMemory Exception,
Exception in thread "MainSocketSession-10.229.6.51" 20:34:12:956 PM java.lang.OutOfMemoryError: Java heap space
I have enabled the -XX:+HeapDumpOnOutOfMemoryError in my application and set the MaX Heap size as 200M. While OutOfMemory erxception thrown, it will wrote hprof file and Java Heap Size is around 38 MB. {color:#3366ff}*Eventhough Heap size exceed, the above thread throws OutOfMemory exception. Why it throws outofmemory??.* {color} Even after outofmemory exception, my application will working fine.
Can you anyone please any one explain why that thread throws OutOfMemory error.
{color:#0000ff}*Heap Size is 38 MB.*
Max Heap Size is set as 200 MB.. but MainSocketSession throws OutOfMemory error, why??
How to analyze and fix this?? .. If you need any additional info .. I will provide you...{color}
Thanks
R.Ravikumar

SmartRavi wrote:
I am running web application on Apache/tomcat with MySQL5.0.46 database. Application server running witout any problem for 2 days and having around 100 threads. One of my threads throws OutOfMemory Exception,Is this running on a Sun JRE or JDK? What version?
Exception in thread "MainSocketSession-10.229.6.51" 20:34:12:956 PM java.lang.OutOfMemoryError: Java heap space
I have enabled the -XX:+HeapDumpOnOutOfMemoryError in my application and set the Max Heap size as 200M. When OOME is thrown, it will wrote hprof file and Java Heap Size is around 38 MB. Even though Heap size exceed, the above thread throws OOME. Why it throws OOME? Even after OOME, my application will working fine.
Can you anyone please any one explain why that thread throws OOME.
Heap Size is 38 MB.
Max Heap Size is set as 200 MB.. but MainSocketSession throws OOME, why??
How to analyze and fix this?Set -Xmx=200m -Xms=200mto rule out the JVM only asking for memory later, when the OS does not have any to give.
If your application decides to allocate a large object (as an example int[50000000] would take 200m)
you will get OOME - the heap will be unaffected (well, a GC cycle will have happened).

Redirecting JVM thread dump to a file

The full thread dump of the JVM can be obtained by pressing ctrl-break in windows on the prompt from which the JVM is run and on solaris by executing the command "kill -QUIT pid" where pid is the process id of the JVM.
The thread dump will be printed on the console by default. But the requirement is to redirect this to a file. The following code redirects the dump to a file "Dump.txt".
System.out.close();
System.setOut(new PrintStream(new FileOutputStream("Dump.txt")));
Here we need to close the standard output stream "System.out" prior to redirecting it to a file. This is because if System.setOut is done without closing it the JVM still gives the thread dump on the initial standard output i.e., console. But if console is closed once we cannot get it back for the rest of the running time of the JVM.
IS THERE ANY SOLUTION TO THIS PROBLEM OF REDIRECTING DUMP TO A FILE, WITHOUT CLOSING THE STANDARD OUTPUT? The application should be able to get the standard output(console) back whenever it's required.

Hi,
I think that you can use a API for logs, as Log4J from Apache or Logger in java.util.logging... both are very simple...
good luck.
Mad.

JVM threads BLOCKED

Similar Messages

Maybe you are looking for