Browser freezes on Theia IDE opening

[mmorhun]

Describe the bug

Whole browser tab is freezed for 30-45 seconds on Theia IDE opening.
Even refresh tab button doesn't work.

Che version

Che master nightly
Che Theia: 7.0.0-rc4

Steps to reproduce

1. Open dashboard
2. Start a workspace from left bar (just created one or already existed - doesn't matter)
3. Wait IDE to be opened. The whole browser tab is freezed for about 30-45 seconds!

Another way:

1. From a running workspace with Theia IDE open dashboard (in the same tab)
2. Switch to IDE again (by clicking Open button from workspace details or from left sidebar
3. Whole tab is freezed for a half of a minute!

Expected behavior

Theia IDE opens in a moment

Runtime

Tested on Minishift minishift v1.34.1+c2ff9cb and Minikube 1.2.0

Screenshots

Installation method

chectl

Environment

Fedora 30, Virtualbox 6.0.8

Additional context

While page is freezed it says Waiting for static.developers.redhat.com

[olexii4]

It is a very annoying bug

[rhopp]

I don't have such big freezes, I also see some error about static.developers.redhat.com in browser console (and maybe few seconds delay) and we have two duplicates reported today.
I think this is something we should fix in 7.0.

[olexii4]

This problem comes with the synchronous request
https://github.com/eclipse/che-theia/blob/master/generator/src/cdn/base.ts#L105
end the error "504 Gateway Timeout". The browser was frozen near 30second

It was reproduced yesterday. It isn't reproducible now. And we have another error "404 Not Found". The browser spends 1ms only.

The logical demand to have the cdn request in ahead. That is why it was done as a synchronous one.

Yes, we can predict this problem on client-side with asynchronous request and timeout, but this solution adds a timeout to regular loading.

The problem with an error 504(Gateway Timeout) is unusual and it is gone. And it is necessary to understand should we live it as is or not.

@l0rd @davidfestal @evidolob WDYT?

[l0rd]

@olexii4 thanks for this analysis. I am removing the blocker label and setting P1 because it looks like an exceptional case.

@davidfestal and @benoitf you have designed/implemented that: how do you think client-side should behave in these 504/404 scenarios?

[benoitf]

I think it would be better to use async request.
The goal is to receive the CDN content as soon as possible but if it's not there, it shouldn't block the flow.

about 504/404 errors well then CDN is not there and it should continue with the other content

BTW @davidfestal CDN is still Akamai's based ? as it's quite unusual to have Akamai's down

[davidfestal]

you have designed/implemented that: how do you think client-side should behave in these 504/404 scenarios?

@l0rd on 404 errors, the use-case is OK: the HEAD / GET requests would return immediately, and the files are loaded from their original location (workspace theia nodejs-based web server).
In fact this is the case for all types of HTTP errors, but the problem with 504 is that the error is triggered after a quite long timeout (gateway timeout). So since the requests are synchronous, the browser is freezed.

I think it would be better to use async request.

The place where the calls are done made it uneasy to send aync requests in those 2 cases (but you might surely provide a better solution). However let me mention that in the 2 sync requests, we're not fetching the content of the main, possibly big, application files. One case is simply a HEAD request (=> without content) to the URL of the real files to download, and the only other case is to fetch the vscode monaco loader javascript file which is rather small.

BTW @davidfestal CDN is still Akamai's based ? as it's quite unusual to have Akamai's down

I've looked into this already, and it seems that the folder containing the CDN files has many olf artifacts that we can remove. I'll do the required cleaning, and will contact the manager of our Akamai account to check if everything is back to normal.

[davidfestal]

I've looked deeper into why che-theia artifacts are not available in the Akamai CDN folder (404 error), and it seems they are simply not pushed anymore during Jenkins builds since a while.

2 main points should be checked:

• The build script only push the artifacts in the BUILD_BRANCH variable is master, as show by the following code: https://github.com/eclipse/che-theia/blob/983351d5ac7545fd76fe035d35131fc23cc0b9e8/dockerfiles/theia/build.sh#L50
  And looking in the last master CI build environment variables seems to show that this variable was not set.
• More generally it seems that when on a release branch (for Che 7.0.0), the artifacts will not be pushed as well.

I will try to gather the artifacts contained in the last release 7.0.0-rc-4.0 docker image, and will push them manually.
However it would be important to fix this for nightlies, the next RC, and mostly for the GA.

@evidolob any idea ?

[davidfestal]

As for adding more robustness in case of 504 timeouts or non-responding URLs, to avoid blocking the browser in these exceptional cases, we've been discussing with @benoitf about possible, quite simple, solutions we could explore.

However I'm not sure we would have time to include this for GA.
@l0rd @slemeur Do you think this should be a high-priority task that could be taken, for example, by the IDE 2 team ?

[l0rd]

@davidfestal that's not a blocker. We can eventually include it in 7.0.0 if we are 100% confident that we are not going to introduce a new regression and we don't have other tasks with higher priority to work on. Otherwise let's just prioritize it for next sprints.

[slemeur]

+1 with @mario Loriedo <mloriedo@redhat.com>

…

On Tue, Jul 30, 2019 at 2:35 PM Mario Loriedo ***@***.***> wrote: @davidfestal <https://github.com/davidfestal> that's not a blocker. We can eventually include it in 7.0.0 if we are 100% confident that we are not going to introduce a new regression and we don't have other tasks with higher priority to work on. Otherwise let's just prioritize it for next sprints. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14039>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMPTIKZPQUJGDFX656GJ4DQCAYSRANCNFSM4IHB7A2A> .

-- Stévan LeMeur // Product Manager // Developer Tools // +336-87-11-27-55

[davidfestal]

@l0rd @slemeur Could we change the milestone accordingly if it's not for 7.0.0 anymore ?

[akurinnoy]

@l0rd @slemeur don't you mind to change the milestone to other then 7.0.0 because it's too dangerous to merge something related to this issue before GA.

[gorkem]

Does this need a known issue on the docs?

[slemeur]

agreed, documenting it would be nice as well. cc @rkratky

[sunix]

looks like this issue is not reproducible anymore. Closing it. Feel free to reopen if someone still has this problem.