Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2109561 | 1.4.2 | Andy Herrick | P2 | Resolved | Fixed | mantis |
JDK-2109560 | 1.2.0 | Andy Herrick | P2 | Resolved | Fixed | 02 |
JavaWebStart application running with the 1.4.0 JRE is creating 2 AWT event queues and events are being dispatched in both queues. This eventually leads to a deadlock in the GUI.
The second event dispatch thread queue seems to become active (ie. an event is actually dispatched to that thread) when using RMI. To be more specific, the "2nd" event queue gets used when a SwingUtilities.invokeLater() call is invoked from a thread that has performed an RMI operation.
This only occurs when launching the GUI via Web Start.
The problem was not seen with 1.3.1. 1.4.0 JRE is being used with JavaWebStart 1.0.1_02. The problem has been reproduced on WinNT 4.0 and Solaris 8.
This problem looks very similar to bug 4476452, which was fixed in JAWS 1.0.1_02 for the 1.3.1 JRE. Also looks related to 4429811.
What the test application does:
The client contains a JFrame, a JTextArea and 2 buttons: Local Update and Remote Update. By clicking on "Local Update" button, in the actionPerformed code, it does the following ( ta is the JTextArea):
public void actionPerformed( ActionEvent e )
{
Runnable localUpdate = new Runnable()
{
public void run()
{
Runnable swingLocalUpdate = new Runnable()
{
public void run()
{
ta.append( "Local update_________________\n");
ta.append( "appContext: " + AppContext.getAppContext().toString() + "\n");
ta.append( "Toolkit: " + Toolkit.getDefaultToolkit().toString() + "\n");
ta.append( "SystemEventQueue:" + Toolkit.getDefaultToolkit().getSystemEventQueue().toString() + "\n");
ta.append( "Current thread: " + Thread.currentThread().toString() + "\n");
}
};
SwingUtilities.invokeLater( swingLocalUpdate );
}
};
Thread t = new Thread( localUpdate );
t.start();
}
By clicking on the "Remote Update" button, in the actionPerformed code, it first starts a new thread and in the thread it invokes a Remote Method HelloI.hello():
public void actionPerformed( ActionEvent e )
{
Runnable remoteUpdate = new Runnable()
{
public void run()
{
try
{
myServer.hello();
}
catch( Exception e )
{
e.printStackTrace();
}
}
};
Thread t = new Thread( remoteUpdate );
t.start();
On the server side, by invoking HelloI.hello() it calls back the client ObserverI.update() through RMI where client observer.update() prints out following info in the JTextArea:
public void update()
{
Runnable swingRemoteUpdate = new Runnable()
{
public void run()
{
ta.append( "Remote update_________________\n");
ta.append( "appContext: " + AppContext.getAppContext().toString() + "\n");
ta.append( "Toolkit: " + Toolkit.getDefaultToolkit().toString() + "\n");
ta.append( "SystemEventQueue:" + Toolkit.getDefaultToolkit().getSystemEventQueue().toString() + "\n");
ta.append( "Current thread: " + Thread.currentThread().toString() + "\n");
}
};
SwingUtilities.invokeLater( swingRemoteUpdate );
}
Test Result:
When clicking on "Local Update", following information is printed in the JTextArea
Local update_________________
appContext: sun.awt.AppContext[threadGroup=javawsApplicationThreadGroup]
Toolkit: sun.awt.windows.WToolkit@e3849c
SystemEventQueue:java.awt.EventQueue@1756a4
Current thread: Thread[AWT-EventQueue-1,6,javawsApplicationThreadGroup]
When clicking on "Remote Update", following inforamation is printed in the JTextArea
Remote update_________________
appContext: sun.awt.AppContext[threadGroup=system]
Toolkit: sun.awt.windows.WToolkit@e3849c
SystemEventQueue:java.awt.EventQueue@1551b0
Current thread: Thread[AWT-EventQueue-0,6,main]
Two different AppContext, EventQueue and Event Dispatch thread is returned in the same client process.
The second event dispatch thread queue seems to become active (ie. an event is actually dispatched to that thread) when using RMI. To be more specific, the "2nd" event queue gets used when a SwingUtilities.invokeLater() call is invoked from a thread that has performed an RMI operation.
This only occurs when launching the GUI via Web Start.
The problem was not seen with 1.3.1. 1.4.0 JRE is being used with JavaWebStart 1.0.1_02. The problem has been reproduced on WinNT 4.0 and Solaris 8.
This problem looks very similar to bug 4476452, which was fixed in JAWS 1.0.1_02 for the 1.3.1 JRE. Also looks related to 4429811.
What the test application does:
The client contains a JFrame, a JTextArea and 2 buttons: Local Update and Remote Update. By clicking on "Local Update" button, in the actionPerformed code, it does the following ( ta is the JTextArea):
public void actionPerformed( ActionEvent e )
{
Runnable localUpdate = new Runnable()
{
public void run()
{
Runnable swingLocalUpdate = new Runnable()
{
public void run()
{
ta.append( "Local update_________________\n");
ta.append( "appContext: " + AppContext.getAppContext().toString() + "\n");
ta.append( "Toolkit: " + Toolkit.getDefaultToolkit().toString() + "\n");
ta.append( "SystemEventQueue:" + Toolkit.getDefaultToolkit().getSystemEventQueue().toString() + "\n");
ta.append( "Current thread: " + Thread.currentThread().toString() + "\n");
}
};
SwingUtilities.invokeLater( swingLocalUpdate );
}
};
Thread t = new Thread( localUpdate );
t.start();
}
By clicking on the "Remote Update" button, in the actionPerformed code, it first starts a new thread and in the thread it invokes a Remote Method HelloI.hello():
public void actionPerformed( ActionEvent e )
{
Runnable remoteUpdate = new Runnable()
{
public void run()
{
try
{
myServer.hello();
}
catch( Exception e )
{
e.printStackTrace();
}
}
};
Thread t = new Thread( remoteUpdate );
t.start();
On the server side, by invoking HelloI.hello() it calls back the client ObserverI.update() through RMI where client observer.update() prints out following info in the JTextArea:
public void update()
{
Runnable swingRemoteUpdate = new Runnable()
{
public void run()
{
ta.append( "Remote update_________________\n");
ta.append( "appContext: " + AppContext.getAppContext().toString() + "\n");
ta.append( "Toolkit: " + Toolkit.getDefaultToolkit().toString() + "\n");
ta.append( "SystemEventQueue:" + Toolkit.getDefaultToolkit().getSystemEventQueue().toString() + "\n");
ta.append( "Current thread: " + Thread.currentThread().toString() + "\n");
}
};
SwingUtilities.invokeLater( swingRemoteUpdate );
}
Test Result:
When clicking on "Local Update", following information is printed in the JTextArea
Local update_________________
appContext: sun.awt.AppContext[threadGroup=javawsApplicationThreadGroup]
Toolkit: sun.awt.windows.WToolkit@e3849c
SystemEventQueue:java.awt.EventQueue@1756a4
Current thread: Thread[AWT-EventQueue-1,6,javawsApplicationThreadGroup]
When clicking on "Remote Update", following inforamation is printed in the JTextArea
Remote update_________________
appContext: sun.awt.AppContext[threadGroup=system]
Toolkit: sun.awt.windows.WToolkit@e3849c
SystemEventQueue:java.awt.EventQueue@1551b0
Current thread: Thread[AWT-EventQueue-0,6,main]
Two different AppContext, EventQueue and Event Dispatch thread is returned in the same client process.
- backported by
-
JDK-2109560 Wrong AppContext used in RMI threads
- Resolved
-
JDK-2109561 Wrong AppContext used in RMI threads
- Resolved
- relates to
-
JDK-4476452 Wrong AWT-Event-Queue-Thread is active with JWS 1.0.1
- Resolved
-
JDK-4429811 Application launched by JWS 1.0.1 has no Swing Display at all (B57)
- Closed