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

Similar Messages

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.

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 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

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.

[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

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 !!!!

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..

A blocking problem of java thread.

Hi!
I would like to execute native thread concurrently in the Java Native Interface.
When a Java thread called a native thread to use java native interface, Java thread is blocking for processing native thread.
So, other java threads don't execute because they are blocking.
Why do these problems occur at JVM(personal basis profile:CVM)?
Regard.
Message was edited by:
peeppeep

you need to explaing the problem more clearly, maybe post the code?

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 concurrency problem - how to know when thread is dead?

My applet uses a thread to draw an iteration graph step by step.
The user as the option of pressing two buttons:
- PLAY button - iteration Points are stored in an arrayList and drawn step by step (a sleeping time follows each step) (drawIterations thread)
- TO_END button - iteration Points are all stored in the arrayList (swingworker thread) and after all of them have been stored the graph is drawn instantly.
I have problems in this situation:
When executing the PLAY-button thread, if the user presses TO_END button, the remaining graph lines should draw instantly. Sometimes I get more points on the graph than I should. It seems that the PLAY thread, which I stop when TO_END buton is pressed, still remains storing new points into the arrayList concurrently to the new thread created after TO_END button was pressed .
Any ideas?
I'm already using synchronization.
private volatile Thread drawIterations;
public void playButtonClick(JToggleButton btn) {
 pointSet1 = new ArrayList<Point2D.Double>();
 if (drawIterations == null) drawIterations = new Thread(this, "drawIterations");
 drawIterations.start();
public void toEndButtonClick(JToggleButton btn) {
 stopThread() ;
 pointSet1 = new ArrayList<Point2D.Double>();
 computeIterationGraphPointsAndRefreshGraph();
public synchronized void stopThread() {
 drawIterations = null;
 notify();
private void computeIterationGraphPointsAndRefreshGraphs() {
 SwingWorker worker = new SwingWorker() {
 public Object construct() {
 // compute all iteration points
 //repaint graph
 worker.start();
}Is there a way of testing if a thread is actually dead after setting the thread object to null??

In general, a Thread keeps running until it's run
method completes. Threads don't stop when their
handle is set to null. Your run method should
constantly be checking on a variable to know when to
stop running and exit the run method. In this case,
you could check on the drawIterations variable to see
if it's null. 
 Even using the following line on my run method I get the the same problem:
 
 while (myThread == drawIterations && drawIterations!=null && halfStep < 2 * totalIterations) {
 ...
 
 Here's the whole method:
 (actually there are 2 graphs being drawn and the second is only refreshed every 2 steps:)
 
 public void run() {
 Thread myThread = Thread.currentThread();
 int totalIterations = transientIterations +iterationsToDraw ;
 while (myThread == drawIterations && drawIterations!=null && halfStep < 2 * totalIterations) {
 computeNextHalfIterationGraphPoint( );
 if (!TRANSIENT_IS_ENABLED || halfStep >= 2*transientIterations ) {// is not in transient calculations
 graphArea1.repaint();
 if (halfStep%2 ==0 ) graphArea2.repaint();
 if (halfStep < 2*totalIterations){//no need to execute the following block if at last iteration point
 if (lastIterationPointsFallOutsideGraphArea(toEndCPButtonActive)) break;
 try {
 Thread.sleep(sleepingTimeBetweenHalfIterationRendering);
 if (threadInterrupted ){//if clause included to avoid stepping into a synchronized block if unnecessary
 synchronized (this) {
 while (threadInterrupted && myThread==drawIterations ) wait();
 }
 }
 } catch (InterruptedException e) {
 break;
 }
 }
 }
 stopThread();
 }

Future.get and the event despatch thread blocking

neeeyaaarghhhh
been tying myself in knots thinking about this
Following one of the java tech tips I've been using Callable and Future objects when I want to return a result from a task, in my case it's usually some file processing
So I have a file chooser gui, I select a file and launch my Callable and await the result in Future.get...
Now the problem is... Future.get I understand blocks the calling thread until the computation / work in the Callable is done and the result returned. In this case the blocked thread will be the event despatch thread... which causes problems as during my file reading I have a JProgressBar running and updating. Well at least I did, now it doesn't show up at all as all the updates to the JProgressBar via invokeLater are queued (as event despatch thread is blocked) until after the work thread has finished
How do I launch a Callable, await the result and have some limited gui activity as the task progresses? The only solution I've found is to have the ProgressBar in a modal dialog, to block out the rest of the gui like this whilst I do the work in the event despatch thread (and drop the idea of threading altogether)
Is my mental modal of how worker threads should spin off from the event thread flawed or am I just missing some 1 line command?

In the situation of updating the gui, you usually want to pass some sort of callback object to the asynchronous code and have that callback method run on the gui event thread.
public class GuiClass {
public void handleResult(Object data);
public void startTask() {
threadpool.execute(new Runnable() {
    public void run() {
      // ... do asynch work ...
      final Object myResult = ...;
      SwingUtilities.invokeLater(new Runnable() {
        public void run() {
          handleResult(myResult);
}In this code, the startTask method is called on the gui thread. it starts some async work on the threadpool. when finished, the asynch task queues the result to be handled back on the gui thread. the handleResult method is called later on the gui thread with the final result. thus, no blocking of the gui thread.
The Callable interface is great for when the invoking thread needs to wait for a result, but you pretty much never want to do this with the gui thread.

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?

ArrayBlockingQueue - consumer thread blocks all threads on poll

I have two threads - A is producing and B is consuming
Thread A calls offer with a 200 millisecond timeout.
Thread B calls poll with a 5 second timeout.
(I'm using an ArrayBlockingQueue)
The problem is that thread A does not continue to run until thread B finishes blocking for the full 5 seconds. Shouldn't the scheduler be allowing Thread A to run while B is blocked on an empty queue?
Thanks for any help!
Edited by: nw1968 on Jul 14, 2008 8:37 AM

In the following test, A doesn't wait for long for B and the while thing runs in under a second.
public class BlockingQueueTest {
 public static void main(String... args) {
 final BlockingQueue<Integer> q = new ArrayBlockingQueue<Integer>(5);
 Thread a = new Thread(new Runnable() {
 public void run() {
 try {
 for (int i = 0; i < 100; i++) {
 System.out.println(new Date() + ": Queue offer " + i);
 while (!q.offer(i, 200, TimeUnit.MILLISECONDS))
 System.out.println(new Date() + ": Queue full.");
 q.offer(Integer.MIN_VALUE, 60, TimeUnit.SECONDS);
 } catch (Exception e) {
 e.printStackTrace();
 Thread b = new Thread(new Runnable() {
 public void run() {
 try {
 do {
 Integer i = q.poll(5, TimeUnit.SECONDS);
 if (i == Integer.MIN_VALUE)
 break;
 System.out.println(new Date() + ": ... poll => " + i);
// Thread.sleep(250);
 } while (true);
 System.out.println(new Date() + ": ... finished.");
 } catch (Exception e) {
 e.printStackTrace();
 a.start();
 b.start();
}

Thread-safety problems

I assume calling setText() for a JLabel and JButton is not thread safe by default. What if I only do this from one single thread other than the event-dispatching thread?
Please help me clarify this.

I was going to start my own thread, but this one looks just perfect.
First of all, according to the API for JTextComponent (and JEditorPane), the method setText() IS ALREADY THREAD SAFE.
"This method is thread safe, although most Swing methods are not."
So you should always be able to call setText() on a text component without sticking it in an invokeLater() block.
Now that I've said that, I seem to have encountered proof that setText() is NOT thread safe... observe the following stack trace:
java.lang.ArrayIndexOutOfBoundsException
        at java.lang.System.arraycopy(Native Method)
        at javax.swing.text.BoxView.updateLayoutArray(Unknown Source)
        at javax.swing.text.BoxView.replace(Unknown Source)
        at javax.swing.text.View.updateChildren(Unknown Source)
        at javax.swing.text.View.changedUpdate(Unknown Source)
        at javax.swing.text.html.BlockView.changedUpdate(Unknown Source)
        at javax.swing.plaf.basic.BasicTextUI$RootView.changedUpdate(Unknown Source)
        at javax.swing.plaf.basic.BasicTextUI$UpdateHandler.changedUpdate(Unknown Source)
        at javax.swing.text.AbstractDocument.fireChangedUpdate(Unknown Source)
        at javax.swing.text.html.HTMLDocument.fireChangedUpdate(Unknown Source)
        at javax.swing.text.html.HTMLDocument$HTMLReader.adjustEndElement(Unknown Source)
        at javax.swing.text.html.HTMLDocument$HTMLReader.flush(Unknown Source)
        at javax.swing.text.html.HTMLEditorKit.read(Unknown Source)
        at javax.swing.JEditorPane.setText(Unknown Source)
// remaining stack trace from my program, omittedThat's a swing-thread bug if I ever saw one (and I've seen THOUSANDS)
Moving right along... my specific problem is that I am calling setText() on a JTextPane. Here's the weird part: If I call setText() normally, all is good. If I call setText() from inside a invokeLater() block (to avoid the above extremely rare exception), it fills the JTextPane, --BUT-- it is then scrolling the JTextPane to the bottom! (Normally, it just leaves it at the top, which is where I want it to be)
Does anybody know if this is normal behaviour or erratic? Should I just add a workaround to set the scroll back to the top, or is there a deeper problem I should be looking for?

Thread Blocked Problem

Similar Messages

Maybe you are looking for