High CPU due to many server connect requests from design view

[mebeingken]

Wappler Version : 3.3.2
Operating System : mac

Expected behavior

The CPU should be utilized and even peak during intensive activities, but revert when complete.

Actual behavior

On a daily basis I see this:

How to reproduce

I’ve held back reporting a bug as it is difficult to create a reproducible condition. But this has gone on way too long. Restarting Wappler always clears the condition. If left alone, and letting the computer sit idle, the condition does not clear.

I spend much of my time in a mobile app, so using the build options for iOS and Android are used often. XCode and Android Studio are typically also open.

Here is the system in question:

@George what can I do to provide more information?

Are there things that will show in on your side in Sentry?

[George]

Does it gets triggered on specific page only?

Or a combination of pages/elements?

Or is it after a specific action in the editor?

Does it help if you close the tab only?

Or the main window?

Does it run on high cpu even if you don’t do anything?

What if you close the main window - do you still see high cpu?

Any information to isolate and be able to reproduce the issue will be very helpful.

[George]

Btw is it an older Wappler installation? A clean install might help as well:

Reinstall Wappler from scratch

Sometimes you need to do a completely clean install of Wappler. You won’t be losing anything as Wappler is fully self containing and also your project preferences are stored in the project folders. You will only loose your projects list but you can recreate it easily later on with the “Open Existing Folder” option in the Wappler Project Manager. Here is how to do a full clean reinstall: On Windows Close Wappler and its launcher by right clicking on the tray icon and choosing Quit on Window…

[mebeingken]

Does it gets triggered on specific page only?
My gut reaction is No. However, the head page is almost always open, so I suppose it could be the trigger. The other content pages come and go depending on what I’m working on.

Or a combination of pages/elements?
See above.

Or is it after a specific action in the editor?
For a while I was theorizing that it was the build process, but I can’t confirm that as a build does not always trigger the issue after a fresh restart of Wappler.

Does it help if you close the tab only?
I don’t believe so, but I will close tabs when this happens again and try to wait out the process.

Or the main window?
By main window you mean close here, rather than Wappler Quit, correct?

Does it run on high cpu even if you don’t do anything?
I’m rarely not doing anything. But once it triggers, doing nothing and waiting it out does not clear the condition.

What if you close the main window - do you still see high cpu?
I’ll try.

[mebeingken]

I did a clean install a week or so ago to try and clear something else.

[George]

@mebeingken

By main window you mean close here, rather than Wappler Quit, correct?

Exactly

[mebeingken]

I have found at least one culprit.

Found this error constantly being generated when in design view. If I disable App Connect, the errors continue. If I code to code view, the errors continue counting upwards on the design view panel – In other words, when I leave design view and come back, the counter does not reset and in fact has gone up substantially.

The errors are being triggered on server connect files that have autoload turned off. However, I do have a dmx-bind:url that could be causing this.

<dmx-serverconnect id="check_login" url="https://dev.popdish.io/dmxConnect/api/1/20/security/check_login.php" dmx-bind:url="https://{{pre_load.data.config.api_server}}security/check_login.php" site="Foodie-Server" noload="noload"
			onsuccess="setTimeout(checkAnimation, 250);">

[George]

Ah yes that’s it!! If you are firing 1000s of requests then you will get a high cpu yes

Somehow your dynamic expression is constantly changing maybe you are in a loop.

Also is the CORS enabled on your server connect side?

[mebeingken]

Well, keep in mind this works perfectly outside of the editor…no errors.

The server action that gets this dynamic data only runs once, so I’m not doing anything to cause a loop.

CORS origin = *

[George]

Well something is continuously triggering it, changing the data.

Maybe send the page to @patrick

So if you remove the dynamic url - all is back to normal?

Good that you are not paying google per request for your server api calls

[mebeingken]

Was just going to say, that there is a variable involved. The variable however is static–I just set it manually to see dev data instead of production.

There is no way I can remove the dynamic-url – every one of my server connects uses this.

I’ll look further and then send over to Patrick.

[mebeingken]

@George

@mebeingken

By main window you mean close here, rather than Wappler Quit, correct?

Exactly

@George The answer to this is Yes. If I close the main window rather than quitting Wappler, the high cpu condition clears.

However, it does NOT clear, if I close all the file tabs.

[George]

Well I think in your case, as we established above, the high cpu was caused by the many server connect requests in design view.

I presume that if you do not open that page with the dynamic server connect url - no high cpu occurs?

[patrick]

Where is the data pre_load.data.config.api_server being set and what value would it be on your dev server? It seems to generate an invalid url with an invalid domain name, the error just tells that it could nor resolve the name which is probably the domain name that is invalid.

[mebeingken]

Thanks @patrick

pre_load.data.config.api_server is a server connection action run once in the onDeviceReady listener:

dmx.parse("pre_load.load({version: '" + BuildInfo.version + "'})");

pre_load server connection action:

<dmx-serverconnect id="pre_load" url="https://dev.popdish.io/dmxConnect/api/1/20/pre_load.php" dmx-bind:url="https://{{env.value}}.popdish.io/dmxConnect/api/pre_load.php" site="Foodie-Server" dmx-param:version="app_version.value"
			noload="noload" dmx-on:success="app_load.load({});check_login.load()">
		</dmx-serverconnect>

And the domain is set using a static variable (static in that it does not change in the code, but rather is set manually before a build.

<dmx-value id="env" dmx-bind:value="'dev'"></dmx-value>

[patrick]

With the noload being set it should not load the url unless the load action is being called. The onDeviceReady is never called inside the design view, so that can not trigger the load.

Do you perhaps have a server connect on the page with a dynamic url that doesn’t have the autoload disabled?

[mebeingken]

Just confirmed, no server connects with autoload enabled.

But also, in confirming this, I’m realizing the errors don’t happen every time I open this page (index.html)…I’ll keep it open and see if something triggers a change.

[mebeingken]

Ahh, that was easy. I can consistently trigger the huge amounts of (ERR_NAME_NOT_RESOLVED) by changing the value of the env variable while App Connect mode is enabled (with App Connect mode disabled, no errors.) I am changing from ‘dev’ to ‘production’ both of which produce valid domains that work outside of the editor (ie. from the app, from the admin web app, etc.)