JDK-4886212 : Need general-purpose way to dispatch object invocations on Java GUI thread
  • Type: Bug
  • Component: other-libs
  • Sub-Component: corba:idl
  • Affected Version: 1.4.1
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2003-07-03
  • Updated: 2003-08-20
  • Resolved: 2003-08-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 02Fixed
Description
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().

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_02 FIXED IN: 1.4.2_02 INTEGRATED IN: 1.4.2_02
2004-06-14

EVALUATION this bug will be transfered to ireland CTE, so i summarize my understanding of the current plan here. all the information and suggestions are due to Ken Cavanaugh. in 1.4.x do as the bug requester suggested: make public the addThreadInfo, etc. 3 functions POACurrent in com.corba.se.internal package in 1.5.x --- quote from Ken's email --- Basically, analogs of the same three methods are available in JDK 1.5 on the class com.sun.corba.se.spi.orb.ORB which is the SPI interface available on the ORB return from the org.omg.CORBA.ORB.init() call: just narrow org.omg.CORBA.ORB to spi.orb.ORB. It has the following methods: public abstract OAInvocationInfo peekInvocationInfo() ; public abstract void pushInvocationInfo( OAInvocationInfo ) ; public abstract OAInvocationInfo popInvocationInfo() ; which manage a thread-local stack of OAInvocationInfo instances in the obvious way. I think all that the accessibility folks need to do is what they are currently planning, where they get the OAInvocationInfo using peek, then pass this data into the event loop thread, where they push it using these same methods (different thread now), dispatch to the actual servant (running on the event loop thread), and then pop the data again. ------------------------------------------------ ###@###.### 2003-08-08
2003-08-08