Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #219086 +++ By fixing bug 219086, a problem surfaced that resides in the SystemRegistry and the way how asynchronous events are dealt with: SystemRegistry.moveHosts() fires (asynchronous) events which include the delta for moving the hosts. There are two problems with this approach: (1) in HostMoveTest.moveLastHost() an event is sent for the last host to move +1, even though this is not possible: The SystemRegistry does not really move that host inside its profile, but still a corresponding event is sent. That event can fail with an SWT Exception later in the SystemRegistry, because by moving +1, no prvious / next item can be found. Suggested solution is to NOT SEND a move event in case the actual move has not been performed in the SystemRegistry. (2) When firing events, SystemView creates its ResourceChangedJob, which extends UIJob. Through Job.schedule() this Job is ALWAYS executed asynchronously, even if the actual event firing happened synchronously. So, at the time the ResourceChangedJob is executed in order to perform the actual move, the items in question might not exist any more. Suggested Solution: The ResourceChangedJob must check whether it can still perform its work (or the system state has changed since the event). Potentially, we should rethink the whole concept of sending a MoveHosts event including a delta. Perhaps it would be better to just ask all views refresh their contents based on what they find in the SystemRegistry, rather than telling them a concrete action to perform (which might be invalid at the time the action is finally performed). If we agree that a complete refresh of the SystemView is not too costly that would be the safest (and my preferred) solution. RSEInternalFrameworkTestCase.testWaitAndDispatch() fails on my machine when running RSECombinedTestSuite. * Using a Workspace on RSE HEAD. * Using the "RSECombinedTestSuite" checked-in teamConfig Launch for JUnit Plug-in test in Run mode * Using Sun 1.4.2_13 JRE * Problem happens only when running RSECombinedTestSuite. - Does not happen when running testWaitAndDispatch alone - Does not happen when running RSEInternalFrameworkTestSuite * The test runs "With all Workspace and enabled target platform plugins". For me, these are: - Target Platform: Eclipse 3.4M5, CDT 5.0M5, EMF 2.4M5 + PHPEclipse 1.2.0-Nightly (From their update site) + Subversive from Ganymede M4 with SVNKit connector + DSDP-DD from Europa + WindRiver Retriever + ECF from Ganymede M4 + SWT MemMonitor + RSE M5 Candidate Build + J9Launching Plugin - Workspace: + RSE, Terminal, Discovery, RemoteCDT + TCF from WR SVN Repository + RXTX latest + org.eclipsecon.tmtutorial EclipseCon 07 RSE Examples plugin (adapted to Latest RSE, from SVN) - This contributes an RSE Event Logging View Attached are the traceback and the console log. I tried a clean build but the failure remains reproducable. I switched to an 1.6.0_02 JRE but the problem remained. I ran the plug-in test in the debugger with an exception breakpoint on java.lang.NullPointerException, and it produced traceback2.txt (attached), this might be the source of the problem. I ran a modified Launch where I disabled RXTX, TCF, DSF, PHPEclipse, CDT, RSE-Examples, EclipseCon-Examples, but the problem remained. Then also disabled ECF, Subversive, MemMonitor but the problem remained. -----------Enter bugs above this line----------- TM 3.0M5 installation : eclipse-SDK-3.4M5 (I20080207-1530), cdt-4.0.0M5, emf-2.4.0M5 DSF-N20071113, ECF-2.0m4, PHPEclipse-1.2.0-Nightly, Releng.Tools-3.4M5, Subversive-0.7.0m4, SWT-MemMonitor, WR-Retriever-3.0.v20070604 RSE install : RSE-SDK-I20080212-2045, TM-terminal, TM-discovery java.runtime : Sun 1.6.0_02-b06 -Xmx512m -XX:MaxPermSize=128m os.name: : Windows XP 5.1, Service Pack 2 ------------------------------------------------ systemtype : Windows-local, Dstore-win, Dstore-linux targetos : Red Hat Enterprise Linux WS release 4 (Nahant Update 3) targetuname : Linux parser 2.6.9-34.EL #1 i686 athlon i386 GNU/Linux targetvm : Sun Java HotSpot(TM) Client VM (build 1.4.2_12-b03, mixed mode) ------------------------------------------------
Assigning M6 to resolve since event handling is a VERY sensitive area, and it looks like this issue needs some general investigations.
See bug 219086 comment 2 for some additional thoughts and suggestions.
The easiest way to reproduce this is putting a breakpoint on SWT.error() and then executing the test suite in the debugger.
I'm assuming that this is really due to the desire to move hosts up and down in the system view. It seems to me that the order of hosts inside the system view is a property of the view and not a property of a profile. There can be several profiles visible in the view, moving a host inside a profile to accomplish a view change seems odd. Therefore, there is no need for a profile operation and no need for events at all. Furthermore, if I share a profile, does that autmatically imply I want to share the ordering? Should the memento used to remember host positioning apply simultaneously to both system view and the system table view? If so, there seems to be a need for a new kind of event that's really not a model change, but something else. At some point we should be supporting multiple instances of these views. If one reorders one instance does this affect all instances?
I'd see the ordering as a property of the model (in ISystemRegistry) though it's not necessarily persisted in the Profile(s) but maybe separately. In addition to the model-ordering which users can manually modify and which is consistent across all views, users may want to use a ViewerSorter in any view to present the model in a different order (which can vary between views and is a view-local property). But I'd propose that any view which provides a ViewerSorter disables or doesn't even show the up/down buttons for manual ordering.
Moving to M7. I will see what we can do to preserve the ordering across sessions. The ordering will be a model ordering, thus all views will be updated if ordered in one view. The table and monitor views will be updated if they are not being sorted. Adding a view sorter to the System View should be considered an enhancement and another bug report written for that.
Bulk update of target milestone
Moving non-UI, non-API bugs to M7
Bulk moving 3.3 deferred items to 3.3.1
Moving to future and leaving open so that we can address this event handling.
