UI Freeze on open LaunchConfigurations dialog while the target platform is being resolved #1567
Comments
It is highly unlikely that the job manager is suspended at that time.
This is a known problem already, but it shows a busy cursor, so I'm not sure the UI is really frozen... |
see screenshot: |
|
Then
seem to use the busy indicator incorrectly (what would of course not help in you need to wait 2min). |
|
It's clear that the target platform is currently being reloaded
So the target platform is reloading for whatever reason and that can take arbitrarily long depending on the network, what's in the pools, and so on. Until it's finished, there's really not so much you can do. The classpaths are not determined and set up properly, the overall state of the workspace bundles and target bundles is in flux. So while things are in this state of flux, something tries to get exactly the state that's being built in the background and does that on the main thread. The dialog has always done that, so no change of behavior here. Agreed that could be handled more gracefully, but no matter what, it/you will need to wait for everything to finish regardless of how graceful that waiting behavior might be presented to you. (It does properly show a busy indicator.) Looking deeper at the guards:
either there is no profile, the resolution is being forced, or the definition has changed and we've not already detected an error yet. If the guards prevented re-resolution, the process would complete extremely quickly from cached information. When I set a breakpoint there, it gets here and the digests are equal:
If I leave that breakpoint stopped, then in the IDE I can try to look at launch configurations. Not surprisingly I am stuck here:
And indeed, it must wait for object 103, i.e., for resolution to complete:
These locks have always been like this and they are necessary. As such, I see nothing to indicate a regression. The recurring problem is that your target platform needs resolving. And now, even with Oomph using a cached resolved state except when force == true or the definition has change, and even with the resolve is not happening while the job manager is suspended, you definitely still need to resolve and it is being properly done on a background thread. That all seems the opposite of a regression. The fundamental point is that the need to resolve cannot be avoided. You will need to be patient. I think the title of this issue is more properly:
I do not personally have the resource to make the presentation of this delay prettier or more helpful than the current busy indicator. I wonder, if you gracefully shut down this IDE and restart it, does the same problem recur? I would definitely not expect that. If I restart my normal SDK IDE, and immediately open the launch configurations, I see no such problem. |
|
It did not reoccur (yet). I rate it regression because it never happened before when opening launch configuration dialog. Until now it used to be a slow start of eclipse IDE but now IDE looked like it started fast and ready for user input bot froze on first user input. At least it did not dead lock (hang forever) anymore :-) |
|
From my side I see only improvements. The IDE does not block indefinitely waiting for jobs that cannot start, the IDE does not load a target platform on the main thread so startup is quick. In addition, the work that should be done on a background thread is being done on a background thread. And finally, something that will not be obvious but is also at play is that the targlet container caches the locations of the bundles and features from the composed target and generally reuses those, so on a typical startup there will be no internet access to p2 update sites, i.e., improved background performance. Nevertheless this issue labels performance and regression, both of which I assert are speculative at best; you might imagine that people who spent significant time improving the behavior and the performance will not look so favorably upon such speculation. Alas, such is how it is... |
merks
changed the title
A workspace that used to not start, now froze the UI for ~2min when in opened LaunchConfigurations Dialog, progress bar shows "initializing plug-in models"
probably regression from #1552
threaddump shows a lot of tasks that should happen in the background only:
The text was updated successfully, but these errors were encountered: