Community
Participate
Working Groups
Build Identifier: Build id: 20100506-2000 If a profile (with <100 elements) is edited, the response times are very bad: after a click on a stereotype within a profile diagram, it takes 5-30 seconds before the object is actually selected. During this delay, there is apparently no CPU consumption, might be an unnecessary network request. Reproducible: Always Steps to Reproduce: 1. Open a UML profile. 2. Select different stereotypes successively within a diagram. 3.
(In reply to comment #0) > Build Identifier: Build id: 20100506-2000 > > If a profile (with <100 elements) is edited, the response times are very bad: > after a click on a stereotype within a profile diagram, it takes 5-30 seconds > before the object is actually selected. > During this delay, there is apparently no CPU consumption, might be an > unnecessary network request. > > Reproducible: Always > > Steps to Reproduce: > 1. Open a UML profile. > 2. Select different stereotypes successively within a diagram. > 3. Could not reproduce on Helios M7, this may have been solved or may be a linux specific issue.
(In reply to comment #1) > (In reply to comment #0) > > Build Identifier: Build id: 20100506-2000 > > > > If a profile (with <100 elements) is edited, the response times are very bad: > > after a click on a stereotype within a profile diagram, it takes 5-30 seconds > > before the object is actually selected. > > During this delay, there is apparently no CPU consumption, might be an > > unnecessary network request. > > > > Reproducible: Always > > > > Steps to Reproduce: > > 1. Open a UML profile. > > 2. Select different stereotypes successively within a diagram. > > 3. > > Could not reproduce on Helios M7, this may have been solved or may be a linux > specific issue. I can reproduce it here with the latetest nightly build and Helios RC3. However, 1. it does not happen right from the start. It is apparently triggered by executing a copy-paste operation on the diagram. 2. It is not limited to the profile diagram, once the paste-operation (in any diagram) has been done, it affects all diagrams. The editor becomes unusable until a restart
(In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > Build Identifier: Build id: 20100506-2000 > > > > > > If a profile (with <100 elements) is edited, the response times are very bad: > > > after a click on a stereotype within a profile diagram, it takes 5-30 seconds > > > before the object is actually selected. > > > During this delay, there is apparently no CPU consumption, might be an > > > unnecessary network request. > > > > > > Reproducible: Always > > > > > > Steps to Reproduce: > > > 1. Open a UML profile. > > > 2. Select different stereotypes successively within a diagram. > > > 3. > > > > Could not reproduce on Helios M7, this may have been solved or may be a linux > > specific issue. > > I can reproduce it here with the latetest nightly build and Helios RC3. > However, 1. it does not happen right from the start. It is apparently triggered > by executing a copy-paste operation on the diagram. > 2. It is not limited to the profile diagram, once the paste-operation (in any > diagram) has been done, it affects all diagrams. The editor becomes unusable > until a restart This seems to be a KDE4/eclipse issue: the editor behaves "normal" again, after the Klipper (KDE clipboard tool) history is cleared. Deactivating the klipper tool does not solve the issue. Lamine: can you confirm that there is no problem on Ubuntu (gnome instead of KDE)?
In my machine there are no problem for the selection of different stereotypes within a profile diagram. I use gnome (ubuntu 10.04) and Papyrus: 0.7.0v201006161830 and eclipse : Version: Helios Release (3.6.0) Build id: 20100603-0907
I finally traced down this bug. It is caused by a deadlock of the GUI thread: The operation getPasteViewCommand in DefaultPasteCommand.java (within the papyrus pastemanager plugin) retrieves the available data flavors (formats) from the clipboard. DataFlavor[] dataFlavors = Toolkit.getDefaultToolkit().getSystemClipboard().getAvailableDataFlavors(); In case of Linux, I traced down this call to a call of the operation XConvertSelection (by using the complete Java sources which are not part of the default JDK). Afterwards, the threads waits for a response from X11 in a polling loop with a timeout of 10s. This timeout may vary on different systems. The problem is that XConvertSelection (see extract from the manual page below) does not know itself which data formats are available but demands the application which has deposited the selection to the clipboard, i.e. Papyrus. Papyrus would normally handle this request using its GUI thread (I guess, it's an incoming GTK event handled by the SWT main loop - though I have not checked it), but this thread is busy waiting for the reply within getAvailableDataFlavors, i.e. the polling loop will not exit before the timeout is passed. This is very criticil for the user, since the whole eclipse application is stalled for 10s. PLEASE GIVE FEEDBACK, if you have this problem (1) in GNOME based applications (which is likely) as the JDK and/or GTK implementation is the same. (2) in Windows Notice however that the default timeout might be much smaller than those I have on my system, i.e. try if the reactivity is a bit worse after copying a selection. There is a simple workaround of not calling getAvailableDataFlavors in the pastemanager. Another workaround would be to copy a selection only to the clipboard of the editing domain, i.e. do not copy in addition to the system clipboard (btw: the EMF command CopyToClipboard does only that, the Papyrus model explorer uses this command and does therefore not copy a selection into the System clipboard - it gets copied to the system clipboard however, once a selection is done in the graphical editor). Other ideas? ---- man page from XConvertSelection: XConvertSelection requests that the specified selection be converted to the specified target type: o If the specified selection has an owner, the X server sends a SelectionRequest event to that owner. o If no owner for the specified selection exists, the X server generates a SelectionNotify event to the requestor with property None. The arguments are passed on unchanged in either of the events. There are two predefined selection atoms: PRIMARY and SECONDARY.
Created attachment 173622 [details] Workaround for the bug on Linux systems
Raised importance, since the error is not specific to KDE, but happens on all Linux systems (re-tested with Ubuntu distribution). The error does not occur on MAC-OS.
Created attachment 173868 [details] Revised patch Replaces earlier patch which does not activate the workaround in case of the paste operation itself.
Created attachment 173875 [details] mylyn/context/zip impacted classes
(In reply to comment #8) > Created an attachment (id=173868) [details] > Revised patch > > Replaces earlier patch which does not activate the workaround in case of the > paste operation itself. fixed in r2366
The fix is merely a workaround which does not handle all possibly affected platforms (all X11 based, patch only handles Linux).
I am having a similar problem with Helios Service Release 2 Build id: 20110218-0911 on Linux (2.6.9-89.33.1.ELsmp) RH Enterprise Linux WS release 4 (Nahant Update 7) with KDE (3.3.1-17.el4_8.1 Red Hat) or Gnome. SR 1 also had the problem. After saving or frequently during routine editing eclipse freezes for something like 10 seconds. Problem began about a week ago with previous Helios version, but I don't know what triggered it. Problem persisted after restarting eclipse, KDE, and even Linux, and installing Helios SR 1 and 2.
Is this one still valid, after all this time of inactivity?
This works fine in Photon RC2.
