Community
Participate
Working Groups
Set Preferences > Remote Systems > Use Deferred Queries = true. When the Remote Monitor is used to poll a very slow system, and refresh rate is set to 5 seconds, refresh jobs are scheduled very frequently. While a remote monitor's refresh job is running, the RSE Tree only shows "Pending..." so the view elements are not usable. As soon as the result of the query gets visible, "Pending..." is shown again. The Remote Monitor should leave the old view contents intact until its new results are available from the remote system. Only then, the old data should be replaced with the new one.
Dave can you check if this is fixed by 1.0M5?
The monitor view is driven by SystemDeferredTableTreeContentManager which extends DeferredTreeContentManager. DeferredTreeContentManager is responsible for creating the "Pending..." item and then collecting results to show in the view. I'm not sure if we should be interfering with that standard Eclipse behaviour.
Any thoughts about this?
Looking ata the view here again and I really don't see any problems. I'm going to mark it as fixed - feel free to reopen if you still see a problem.
The problem is in the interaction of the two views. The monitor is causing an automatic refresh of the Systems View at the point of the monitor. If I monitor the actual host (instead of a folder) the "pending..." appears and the whole tree collapses back to its first level. This makes it very difficult to navigate the tree while a monitor is running since the tree is constantly being refreshed. Both the monitor and the system view are driven from the same model so it may not be possible to dissociate the monitor from the view without some work. I believe folks would see the automatic refresh of the tree when the monitor refreshes as unnatural. Would it be possible or make sense to refresh a copy of a section of the model in the viewer - or perhaps use a filter as a root object that is not visible in the tree? Reopening - I recommend that this be deferred for some continuing discussion on how monitors should work.
Agree -> setting target milestone 2.0 My personal feeling is that the refresh queries from the remote monitor should not show a "pending..." message while they are ongoing. Once the data has arrived from the query, the model (and tree) should be updated without destroying existing selection.
One thing that could simplify this problem a bit would be to turn the Remote Monitor back into a table rather than a table-tree. For the most part the value of this view lies in it's use as table, however others may see the tree aspect of this as an important (albeit problematic) bonus. Any thoughts on that?
I've changed the monitor back from a table-tree to a table since the value of this view is mostly in it's table capabilities. Although this doesn't probably doesn't address the SystemView issue described, it does reduce some of the complexity issues of the monitor.
moving to m6 to look at later
deferring to m7 since it does not seem API is affected
*** Bug 161431 has been marked as a duplicate of this bug. ***
There is little we can do in the RSE framework to fix this, as long as the client subsystems use deferred jobs and the DeferredTreeContentManager. Deferring to after 2.0. The DeferredTreeContentManager is responsible for collapsing tree nodes in order to refresh them. While this is done, the tree node is unusable. The problem might be alleviated slightly when the REFRESH events do a better job maintaining the current selection and expand state, as discussed on bug #173042. Clients can work around this as follows: 1. Have an ISystemViewElementAdapter with supportsDeferredQueries==false 2. Have ISystemViewElementAdapter#getChildren() always return local (cached) model objects 3. Listen to ISystemResourceChangeEvents.REFRESH* events 3a. When a refresh event is received, perform an asynchronous retrieval of data from the remote side, with a callback 3b. When the callback is received, update the local (cached) model and send a REFRESH event that is a subclass of the normal refresh event 3c. Have step (3a) distinguish the special local refresh event from the RSE one, and do not perform the asynchrous retrieval in this case. In other words, the client doesn't use the RSE deferred query / job mechanism but rather performs asynchrouns remote queries itself.
Actually, hacking this up might work as follows: * In SystemView.getContextObject(TreeItem), extend the IContextObject to also contain the TreeItem referring to the requested parent. * In SystemDeferredTreeContentManager.getChildren() get the TreeItem out of the IContextObject in order to get the currently displayed children. Instead of just returning the pendingAdapter, return an array of pendingAdapter AND the existing children, and remember the list of existing children. * At the callback when the deferred getter job returns, Perform a refresh of the remembered old list of children against the new list of children; removing, adding, updating properties where needed. The absoluteName may be needed to do this properly. Also, for those TreeItem children that were expanded at the time of refresh, another deferred job needs to be started now. Finally, when all previously expanded members are returned, apply the selection that was remembered at the very beginning. Basically, this idea applies a similar algorithm as was in place in the SystemView at the time when no deferred queries were supported. Note that with the Local files subsystem, the case of non-deferred-queries can still be tried out: it retains selection and expand state in many more cases. Anyways, I'm not pushing this fix forward any more, since at Wind River we're using the async query method described in comment #12 so it's not so much of an issue for us. A fix for this might be considered for 2.0.1.
