Multiple Dispatch Threads Events Deadlocking Java Web Start Application

Question

I am writing a Java Web Start application, and I noticed that it is freezing. When I dump a thread, I see that the two threads involved in the deadlock are event streams.

When I launch the application locally, there is only one EDT, but when I boot and start through Java Web Start, there is a second.

Can someone tell me why there is a second EDT, and how can I prevent them from interlocking with each other?

edit: After monitoring the application using JVisualVM, I believe that the second EDT is responsible for redrawing the java console window.

Found one Java-level deadlock: ============================= "AWT-EventQueue-1": waiting to lock monitor 0x07e4d8fc (object 0x29c2d950, a java.awt.Component$AWTTreeLock), which is held by "AWT-EventQueue-0" "AWT-EventQueue-0": waiting to lock monitor 0x07e4cbfc (object 0x29c294e8, a java.lang.StringBuilder), which is held by "AWT-EventQueue-1" Java stack information for the threads listed above: =================================================== "AWT-EventQueue-1": at java.awt.Window.getOpacity(Unknown Source) - waiting to lock <0x29c2d950> (a java.awt.Component$AWTTreeLock) at sun.awt.SunToolkit.isContainingTopLevelTranslucent(Unknown Source) at sun.awt.windows.WComponentPeer.isAccelCapable(Unknown Source) at sun.java2d.d3d.D3DSurfaceData$D3DWindowSurfaceData.restoreSurface(Unknown Source) at sun.java2d.d3d.D3DScreenUpdateManager.validate(Unknown Source) at sun.java2d.d3d.D3DScreenUpdateManager.createGraphics(Unknown Source) at sun.awt.windows.WComponentPeer.getGraphics(Unknown Source) at java.awt.Component.getGraphics(Unknown Source) at javax.swing.JFrame.getGraphics(Unknown Source) at javax.swing.JComponent.safelyGetGraphics(Unknown Source) - locked <0x29c294e8> (a java.lang.StringBuilder) at javax.swing.RepaintManager$3.run(Unknown Source) ... at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) "AWT-EventQueue-0": at javax.swing.JComponent.isComponentObtainingGraphicsFrom(Unknown Source) - waiting to lock <0x29c294e8> (a java.lang.StringBuilder) at javax.swing.JComponent.getGraphicsInvoked(Unknown Source) at javax.swing.JFrame.getGraphics(Unknown Source) ... at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) 

Answer 1

we just needed to find a problem that is very similar to yours.

Our findings: Java Webstart launches the creation of multiple EDT threads. If you start your applet as an application, there is only one EDT that would prevent the problem.

We could see activity on the second EDT only when we played with the console window (resize / hide). Resizing constantly made the problem reproducible very easily.

After a short hunt, we were able to find a place in our code where getGraphics is called in the drawing method. This triggered a chain of calls ending at the very top of all the components which appears to be shared with this console.

This probably happens when the application and the console are open, and the computer becomes unlocked by its user, since all components are redrawn simultaneously.

Hope this helps. I would be interested to know any further details about this common mistery component.

Personally, I would not suspect that the console uses a component with a main application that could block each other in this way.

Good luck.

Answer 2

You are correct that AWT-EventQueue-0 is your regular event stream, and AWT-EventQueue-1 is the stream created when the application was launched through the Java web start. (In fact, you will find that the second one is created if your web launch application does not display the console.)

As for the cause of the deadlock, it cannot be said without seeing the full trace of the stack of two threads, but there are several possibilities (in the estimated probability decreasing order!):

• error in video driver
• error in code
• error in jdk