[
https://issues.jboss.org/browse/JBIDE-21158?page=com.atlassian.jira.plugi...
]
Viacheslav Kabanovich commented on JBIDE-21158:
-----------------------------------------------
Loading tree children in a separate non-ui job implied that the process may take a long
time and when this approach is chosen it should not leave a loophole for loading in ui
thread.
By the way, the deriving class ExpressExplorerContentProvider (Openshift 2) overrides
getChildren(Object) in such a way, that collection 'loadedElements' is never used
to retrieve the children loaded in the non-ui job and always causes new call to
getChildrenFor((Object) in ui thread, so that objects that get to 'loadedElements'
may be considered as memory leaked. I have a guess why it was done this way: to prevent
collapsing the expanded tree nodes at refreshes. Maybe that should be reported as a new
issue, but since Openshift 2 is not a priority, I am not sure.
Improve BaseExplorerContentProvider.loadChildren()
--------------------------------------------------
Key: JBIDE-21158
URL:
https://issues.jboss.org/browse/JBIDE-21158
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: openshift
Affects Versions: 4.4.0.Alpha1
Reporter: Viacheslav Kabanovich
Assignee: Viacheslav Kabanovich
Labels: performance
Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
This method may be called concurrently while children for current parentElement are being
loaded. Now for this case implementation calls directly getChildrenFor(parentElement)
which loads children in ui thread. So, if by some reason loading children in a separate
job took a lot of time, by the same reason this second call in ui thread may hang Eclipse
for some time.
Instead, it seams reasonable just to return the available loading stub as a child, when
loading job is completed it will call refresh.
[~adietish] please take a look at the pull request.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)