search

vaadin / flow

Vaadin Flow is a Java framework binding Vaadin web components to Java. This is part of Vaadin 10+.
Apache License 2.0
600 stars 165 forks source link

Vite causing slow, sequential loading of windows in development mode. #15575

Open jflamy opened 1 year ago

jflamy commented 1 year ago

Description of the bug

I have a collaborative (@Push) application which involves updating a dozen different types of windows together in a coordinated fashion. I have a script that runs a subset of the windows to visualize the sequencing of window updates. Each window is opened by a different process to avoid any problem with the number of sockets
image

Even with an already running dev server, loading the windows to get to the stage pictured above takes 30 to 45 seconds (and every few attempts, one or more of the windows fails to load (TypeError: Failed to fetch dynamically imported module: http://localhost:8081/VAADIN/generated/jar-resources/FlowClient.js)

The windows appear to load in sequence. The image below is after 15 seconds. image

Note that the exact same script works perfectly fine when the application is in production mode. I have been running such scripts for several years under Vaadin 10+ and never had such issues.

Minimal reproducible example

Open a lot of windows to an application running in development mode. @Push is used with Jetty, with the default websocket+XHR setting The computer has plenty of memory.

Expected behavior

Less overhead. This did not happen with webpack under V14

Actual behavior

Versions:

Vaadin: 23.3.1 Flow: 23.3.1 Java: AdoptOpenJDK 11.0.10 OS: amd64 Windows 10 10.0 Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36 Live reload: Java active (HotswapAgent): Front end active:

mcollovati commented 1 year ago

Hi, thanks for reporting. A couple of questions to better understand the situation:

Are there any errors reported on server logs? When you get TypeError: Failed to fetch dynamically imported module, what HTTP status code you get? Is it a 404 or 50x?

jflamy commented 1 year ago

Question: I am running Jetty embedded, and under that configuration I do not see the Vite logs. But do not do anything to suppress them. Is there anything required to enable the Vite logs ? Does jetty-run do something special to show them ?

jflamy commented 1 year ago

The only Vite-ish logs that make it to my console are

------------------ Starting Frontend compilation. ------------------

----------------- Frontend compiled successfully. -----------------
mcollovati commented 1 year ago

I was more interested in possible logs from Vaadin on the server side, rather than Vite ones, because requests like http://localhost:8081/VAADIN/generated/jar-resources/FlowClient.js are proxied by Vaadin servlet. But, I suppose, there's nothing evident. What about the HTTP status code of failing requests?

jflamy commented 1 year ago

I am currently unable to replicate the failure. But the sequential accesses remain. To the best of my knowledge I have removed anything that I think could prevent the Vaadin servlet from logging an error, but there are no traces visible of interactions with Vite. Is there a Jetty or Vaadin log that I should activate explicitly with a DEBUG or TRACE level ?

There is another bug open about Vaadin NOT proxying to Vite so I'm a bit confused (my bug https://github.com/vaadin/flow/issues/15574 -- and Artur's reference to https://github.com/vaadin/flow/issues/14773)

mcollovati commented 1 year ago

You can try to activate com.vaadin.base.devserver at DEBUG level. You should at least see what resources are forwarded to Vite

jflamy commented 1 year ago

I tried to reproduce the error loading, but did not succeed in spite of opening hundreds of windows. The only anomaly I can reproduce every 10 runs of the script or so is Vite returning a completely empty page. The request that gave that empty result is at line 4732 of the log (see attached zip file). The other atypical thing is at the end of the log -- requests for sw.js. The empty page returned is literally

<html><head></head><body></body></html>

image owlcms_white.zip

jflamy commented 1 year ago

Another thing I noticed was that if I stop my server and restart it (leaving all the windows open), the very very useful behaviour of reloading the windows takes place. All windows show the "building front-end" banner, but the building appears to take much longer -- as if all windows were effectively triggering a rebuild when one is already under way. This is pure speculation on my part however.