Bug 188160 - [refresh] Refresh does too much work in some cases (query the parent)
Summary: [refresh] Refresh does too much work in some cases (query the parent)
Status: RESOLVED FIXED
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 2.0   Edit
Hardware: PC Linux-GTK
: P3 normal (vote)
Target Milestone: 2.0   Edit
Assignee: David McKnight CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 190803
  Show dependency tree
 
Reported: 2007-05-21 15:30 EDT by Martin Oberhuber CLA
Modified: 2008-08-13 13:20 EDT (History)
0 users

See Also:
dmcknigh: review+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2007-05-21 15:30:59 EDT
Found in the Workbench product which extends RSE. 

For host nodes that have no subsystem connected, Workbench hides the subsystem nodes. When such a host without children is refreshed, the refresh event is sent to its parent (the SystemRegistry), leading to a refresh of all connections.

It turns out that by fixing bug #143458 in SystemRefreshAction, code was introduced which always refreshes the parent in case a node is found to have no children. 
Comments on that bug already indicate that this is not a good solution and leads to much extra work but it's the best that can be done for subsystemts with deferred queries (because there is no adapter API for doing deferred queries on individual nodes).

For subsystems that do not do deferred queries (like the local subsystem), there should be no need for refreshing the parent. Same for elements outside the subsystem context (i.e. subsystem nodes, host nodes).

-----------Enter bugs above this line-----------
installation : eclipse-SDK-3.3RC1
RSE install  : Download RSE-SDK 2.0M7 + Terminal + Discovery + Remotecdt
java.runtime : Sun 1.5.0_10-b03
os.name:     : openSUSE 10.2 Linux x86_64
------------------------------------------------
systemtype   : 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)
------------------------------------------------
Comment 1 Martin Oberhuber CLA 2007-05-21 15:35:43 EDT
Change checked in to SystemRefreshAction.java v1.18 -- Dave can you please review this?
Comment 2 Martin Oberhuber CLA 2007-05-24 08:28:54 EDT
Reopening because code has been added to SystemView.java v1.117 in order to fix bug #187732, where the new code does not comply with the changes made to SystemRefreshAction.java.

These two versions of similar code need to be consolidated, preferrably into SystemView.java because this can be called programmatically by more events from anywhere and not just the action. But the following questions need to be resolved:

* What is the reason why refresh of leaf nodes does not work?
  I have the feeling that this is specific to the RSE Files Subsystem,
  but I'm worried that for our commercial debugger subsystem, this
  seems to be an artificial limitation, causing unnecessary work,
  especially is supportsDeferredQueries() is false. We can live
  with this artificial limitation for now, but then I want an 
  enhancement request for the future to improve the situation
  (could be this bug).

* Does the code in SystemView take care of maintaining the selection?
* Does the code in SystemView take care of the case where a parent is not set?
* Why is code in SystemView in the switch() statement and not in the 
  refreshRemoteObject() method?
Comment 3 David McKnight CLA 2007-05-25 11:53:49 EDT
SystemView should maintain the same selection.  I've updated the SystemView code to check for a null parent so that it doesn't refresh null if there is no parent.  I'm not sure why I was seeing events where the leaf was being passed in when I did this SystemView stuff since your code in refresh should take care of that (although it doesn't take care of the case of a deleted container).  Perhaps that code for handling a deleted container should move to the refresh action.  

One thing that may come up is the potential for the refresh remote event to be fired from other places (other than the action), but then on the other hand, there are other views that need to handle refresh remote (so in that case, the refresh action would solve things).  What do you think?  Should all the logic be in the action or the view event handling?
Comment 4 Martin Oberhuber CLA 2007-05-25 11:56:55 EDT
I'm sure that this code must be with the listeners and not with the action.

The action is a client, and it's not ok if the client needs to do special handling because the implementation, views or listeners have shortcomings. The client says what it wants to do, and the listeners need to ensure they get it done somehow.
Comment 5 David McKnight CLA 2007-06-01 16:05:46 EDT
Are we okay with closing this one?
Comment 6 David McKnight CLA 2007-06-05 15:20:43 EDT
marking this as fixed since the listeners should be doing the work.
Comment 7 Martin Oberhuber CLA 2008-08-13 13:20:15 EDT
[target cleanup] 2.0 RC2 was the original target milestone for this bug