EVALUATION
Name: dsR10078 Date: 02/17/2003
I couldn't reproduce the problem with NetBeans 3.4.1 and JDK 1.4.1.
Since the steps to reproduce the problem are not documented in the bug
description, we can only guess the actual cause of the hang.
On X11 systems, if the current clipboard owner resides in another
application, ClipboardTransferable.getClipboardData() sends a
SelectionRequest to the owner and waits for response. The hang can
happen if the owner never responds to the request for whatever reason
(crash, hang or other malfunction).
###@###.### 2003-02-17
======================================================================
The bug can easily be reproduced in a simple Swing app without using NetBeans. Read
http://www.netbeans.org/servlets/ReadMsg?msgId=457153&listName=nbdev
and specifically point #4. In sum: copy several hundred Kb of data from an Emacs buffer using X clipboard copy mode, then attempt to get the clipboard contents from a Java app. The Java app freezes at once.
I tend to agree that the ultimate problem is not really in Java but in whatever app made the bad paste - Emacs, I think. However the fact remains that the AWT event thread is blocked and there is no recovery strategy in the JRE. For example, in my message I wrote that gEdit (a native app) also has problems retrieving the same paste - but it does not cause the app to hang, it just makes the paste fail. I.e. this is a robustness issue. I don't think it's good if any Java app which uses the clipboard can be suddenly frozen with no hope of recovery due to bugs in another app.
Suggest perhaps that the Motif toolkit's clipboard handler try to access the X clipboard using either a separate thread or a watchdog timer that would let it recover from a defective clipboard event in a reasonable amount of time (say 30 seconds).
It does not seem feasible to work around this bug in NetBeans code, as I wrote in my mailing list message. We could make *most* app clipboard accesses go through some special handling code which would try to call java.awt.Clipboard only in a special thread, which could not block the AWT thread. (It does not seem to be clearly documented whether you have to call data transfer methods from the AWT thread, as for GUI components - does it matter? Is data transfer independently synchronized, or does it rely on a single-threaded access mode?) However there are some kinds of code, e.g. JTextComponent, which will directly access the un-hacked-around system clipboard anyway, and there is no public API or even stable-looking hack to force them to use a special clipboard.
I have only heard of this bug existing on Linux machines, though in principle it might also exist on Solaris.
###@###.### 2003-02-28
Name: agR10216 Date: 03/02/2004
NetBeans team discovered another scenario in which the bug reproduces:
"The user is using the IDE to debug a java app, let's call it Notepad.
In Notepad which is running under the debugger, the user selects some
text and puts it in the system clipboard. Later on Notepad is suspended
at a breakpoint. The user switches back to the IDE which asks the
system clipboard for its contents (to determine if the Paste action
should be enabled, or just because the user hits Ctrl+V). AWT passes
the query to Notepad, the owner of the clipboard, which being suspended
of course cannot answer. We have a reliably reproducible deadlock.
...
This is a serious problem for us, close to be called showstopper..."
Introduction of a system property that specifies a timeout which
Clipboard.getContents() waits for "the owner of the clipboard"'s
reply was proposed.
###@###.### 2004-03-02
======================================================================
Name: agR10216 Date: 03/30/2004
NetBeans worked around the issue, so this bug isn't critical now.
See some useful parts of a discussion in the comments section.
###@###.### 2004-03-30
======================================================================
Refer to http://jplan.sfbay/feature/236, http://ccc.sfbay/4818143
and the comments section of this CR for plans concerning this feature.
---------------------------
Problem
Currently if a Java application requests for clipboard data on
an X platform, then the thread which this request has been
performed on waits for a response of the clipboard owner: it
should provide the data requested or report that the data are
unavailable. A malfunctioning clipboard owner may not answer so
that the thread may wait indefinitely. This issue is especially
annoying in GUI applications if a request for clipboard data is
performed on the thread responsible for processing events,
painting; in such a case a GUI application freezes.
This problem is known to be reproducible only on X platforms,
and initially it was reported against MAWT since the timeout,
which the requestor waits for the data, is ULONG_MAX (practically
the requestor waits for ever).
XAWT has the timeout set to 10000ms, so that the requestor does not
wait indefinitely. Such a timeout appeared to be sufficient even for
large data transfers (there are no known issues with such a timeout).
-----------------------------------
I proposed 3 kinds of API and discussed them with Swing and Netbeans
representatives.
1. Asynchronous API for retrieval of data from the clipboard, i.e.
a listener is registered, and it will be called when the clipboard
contents is retrieved.
Swing rejected this API mainly since it's hard for Swing to adapt to
the API.
2. API that allow the following:
while (! clipboard contents is retrieved) {
if (waiting too long) {
inform (or ask) a user;
break waiting (or continue waiting);
}
wait(some_timeout);
}
if (clipboard contents is retrieved) {
make use of the contents;
}
Also convenience methods, which wrap similar code, could be provided.
Swing rejected the API mainly because of its complexity.
3. Timeout-based API was approved by Swing and Netbeans.
After negotiations with Netbeans and Swing team representatives
it was decided to implement a timeout-based API. Since such an API
is rather low-level, and it isn't cross-platform, it should be
private.
Thus the solution is to introduce a system property which specifies
the timeout in milliseconds, set the default timeout in MAWT to
10000ms as in XAWT (and put actions on the expiry of the timeout
to rights in both XAWT and MAWT).
After the solution was implemented, Netbeans decided
that they need not the system property, so the appied solution
is the same except for introduction of the system property.
======================================================================
###@###.### 2005-05-20 10:58:08 GMT
|
Java