[ https://issues.jboss.org/browse/JBIDE-21590?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich commented on JBIDE-21590: ----------------------------------------------- I have noticed a couple of things that may not cause this issue but be related. OpenShiftExplorerContentProvider.getChildrenFor() for connection always creates and returns new instances of OpenShiftProjectUIModel together with new instance of DeploymentResourceMapper. If previous call for connection children already created such objects and they are in projectCache map, then they are just replaced and lost, but they are not disposed, mappper remains a listener to ConnectionsRegistry, and project adapter to mapper; so that it is a possible memory leak that also actively processes changes. Request for children certainly happens on action Refresh for connection. The adding/removing a connection causes complete content refresh so that project adapters for all projects of all connections will be recreated, leaving old objects lost but not disposed. (Note that method BaseExplorerContentProvider.handleConnectionRemoved() is never called now, it may be called from ConnectionsRegistryListener.connectionRemoved() or removed as dead code.) Now, closer to the issue. It seems possible that getChildrenFor() may be called twice, through launchLoadingJob() and directly by loadChildren() while loadedElements has stub. Then, projectCache may have the other set of project adapters for the connection than returned to viewer as children. If that might be the case, the rest is simple: handleProjectChanges() looks for project adapter by key (connection+project) and requests the viewer to remove it from parent connection node. But it is the wrong instance. Nevertheless, viewer still could remove it if OpenShiftProjectUIModel implemented hashCode() and equals() but it does not. [~jcantrill], could you please look into my guesses. I may have missed something of course. -- This message was sent by Atlassian JIRA (v6.4.11#64026)