-
Bug
-
Resolution: Fixed
-
P1
-
1.4.1
-
02
-
generic
-
generic
Java AWT/Swing is effectively single-threaded. Requests that execute
against Java GUI components often need to execute on the Java GUI
event loop thread.
We have a large number of object interfaces that must execute on the
Java GUI thread but are dispatched by the Java POA on a POA pool thread.
(it is not possible for us to dispatch each method call individually to
the GUI thread within each object implementation)
We can use a Tie class to dispatch each invocation to the Java
GUI thread, but then we get an exception because com.sun.corba.se.internal.POA.POACurrent.peekThrowInternal() uses
a ThreadLocal stack of InvocationInfo objects, and the GUI thread
does not have the stack; only the original POA thread has it.
We can fix this by creating (within a Tie class) the appropriate
InvocationInfo object on a ThreadLocal associated with the GUI thread,
populating it within info from the POA thread's stack,
and then popping it before returning to the regular POA dispatch
method.
We have developed a simple fix that exposes (makes public)
three methods on POACurrent: addThreadInfo(), removeThreadInfo(),
peekThrowNoContext(). We do not believe this is likely to be
an acceptable solution so we would like to work with the
java-idl team to identify a better one.
The attachment AccessibleImpl.java contains our Tie-proxy class
AccessiblePOATieProxy; this shows how we dispatch the
invocation to the GUI thread (in real_invoke, we use
SwingUtility.invokeAndWait() to execute a command
AWTInvocation. The calls to the (formerly) private Java IDL
methods are in this method and in AWTInvocation.run().
against Java GUI components often need to execute on the Java GUI
event loop thread.
We have a large number of object interfaces that must execute on the
Java GUI thread but are dispatched by the Java POA on a POA pool thread.
(it is not possible for us to dispatch each method call individually to
the GUI thread within each object implementation)
We can use a Tie class to dispatch each invocation to the Java
GUI thread, but then we get an exception because com.sun.corba.se.internal.POA.POACurrent.peekThrowInternal() uses
a ThreadLocal stack of InvocationInfo objects, and the GUI thread
does not have the stack; only the original POA thread has it.
We can fix this by creating (within a Tie class) the appropriate
InvocationInfo object on a ThreadLocal associated with the GUI thread,
populating it within info from the POA thread's stack,
and then popping it before returning to the regular POA dispatch
method.
We have developed a simple fix that exposes (makes public)
three methods on POACurrent: addThreadInfo(), removeThreadInfo(),
peekThrowNoContext(). We do not believe this is likely to be
an acceptable solution so we would like to work with the
java-idl team to identify a better one.
The attachment AccessibleImpl.java contains our Tie-proxy class
AccessiblePOATieProxy; this shows how we dispatch the
invocation to the GUI thread (in real_invoke, we use
SwingUtility.invokeAndWait() to execute a command
AWTInvocation. The calls to the (formerly) private Java IDL
methods are in this method and in AWTInvocation.run().