"Reading Project Structure" pop-up

[spillinova]

"Reading Project Structure" pop-up frequent and persistent.

Reproduction Steps:

Imported Web Starter Kit as project
Installed Sass via NPM
Created Sass watch folder

Expected behavior:

Changes to scss file are written to css file in a quick and practical way

Observed behavior:

After Sass auto writes and saves to css file, the "Reading Project Structure" pop-up stays on the screen for about 60 seconds and locks out any further work.

Codenvy version: 5.0.0-M7
OS and version: codenvy/node

Additional information:

Seems impractical for changes in file structure to delay serious front-end development this much.

Problem only started happening recently, didn't happen in an older version of Codenvy: Not sure
Problem can be reliably reproduced: Yes

Diagnostic bundle
Execute the script on this page and post public link to the bundle here.

[TylerJewell]

@dkuleshov - I am fairly certain this is a duplicate bug that was fixed in 5.0.0-M8, though I cannot find the right issue to cross-link. Can you confirm, please?

[AndrienkoAleksandr]

Related eclipse-che/che#3115 but older and maybe not actual.

[slemeur]

Related to eclipse-che/che#2713 and eclipse-che/che#2608

[dkuleshov]

There was a fix to IDE project tree synchronization that was implicitly related to server side file watcher service in eclipse-che/che#2713. However I'm afraid that it does not cover this particular problem. If my memory serves me, the fix supposed to cover just a special case while more general solution was yet to come.

[spillinova]

Do regular users have access to version 5.0.0-M8? My current online version shows 5.0.0-M7

[TylerJewell]

You have to run the nightly version to see an M8 snapshot right now. 5.0.0-latest only provides M7. M8 is due to be released in a few days.

[spillinova]

OK. Thanks.

[TylerJewell]

This is the current list of issues that are still to be completed and the ones already resolved. https://github.com/eclipse/che/issues?q=is%3Aopen+is%3Aissue+milestone%3A5.0.0-M8 Tyler Jewell | CEO | tyler@​codenvy.​com | 9​78​.8​84​.53​55

…

On Thu, Dec 1, 2016 at 1:55 PM, spillinova ***@***.***> wrote: OK. Thanks. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1249 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAX9CofN64HAMuTcnlnAQ4bQNeHh_Yr8ks5rD0JngaJpZM4K_knY> .

[bmicklea]

spillinova we are investigating a workaround in M8 that should help things. We know now what's causing this issue now but the best solution is more complex and will be taken in the next sprint for the M9 milestone.

[JamesDrummond]

Does the current explorer synchronizer implementation read the entire file/folder tree of a project? To increase performance shouldn't we only do the initial scan for the entire file/folder tree of a project or not at all? We should scan and update folders only for the folders expanded in the project explorer tree view. I see no reason to update folders that are not visible in the project tree. When a new folder is expanded do a scan for only that folder to make sure it's up to date. This should be very fast as when I hit the refresh button at the top of the project explorer to refresh a folder currently the changes are shown very quick.

I do not want the blocking pop-up message to go away and still not be able to work because the scanning is taking to much system resources. We need to fix the problem correctly as there is a lot of work done in the file explorer such as copy, rename, deleting etc.

[TylerJewell]

@spillinova - FYI, in our sprint demo reviews for Che this week, @dkuleshov showed us a revision to our file system watchers that make a lot of the analysis on the file system asynchronous. This removes all of the blocking pop-ups that you are watching.

The core issue was that when you are doing something like an npm install or another scaffolding command, all of the file modifications were triggering a lot of events that caused the UI to lock itself up. Now that it is asynchronous, the UI is much smarter about how it will update itself.

Net - the performance was really fast. We saw some very complicated and sizable projects getting restructured and it was seemless for the end user.

We expect this PR to be opened and merged shortly, and it will be part of M9.

[dkuleshov]

Mentioned pull request is here: eclipse-che/che#3482. It is now under heavy testing and will be merged after tests will pass. It should significantly improve overall performance and remove blocking pop-ups in most cases, however there are a few issues that should improve performance even more to fix most rare cases. They are in analyze/progress stage and should also be resolved shortly: eclipse-che/che#3467, eclipse-che/che#3466, eclipse-che/che#3465. These are all UI related tasks. There is also a task to document new file watcher service capabilities: eclipse-che/che#3461

[vzhukovs]

There was a small workaround committed into master branch (PR: eclipse-che/che#3520) to disable UI blocking. Later a new solution will be provided because this problem needs more complex solution which can impact code refactoring of IDE client's core components.

[bmicklea]

@spillinova I am closing this issue because the change made solves the blocking behaviour. We'll do a bigger change to further improve in the next release.