Open jflamy opened 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?
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 ?
The only Vite-ish logs that make it to my console are
------------------ Starting Frontend compilation. ------------------
----------------- Frontend compiled successfully. -----------------
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?
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)
You can try to activate com.vaadin.base.devserver
at DEBUG level. You should at least see what resources are forwarded to Vite
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>
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.
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](https://user-images.githubusercontent.com/678663/209736669-69b3b09f-a157-4737-89ae-e938719461c6.png)
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](https://user-images.githubusercontent.com/678663/209737096-2f57ce32-3c40-46f3-9f34-7c9ff9cf1b18.png)
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: