This topic is the discussion thread for the Vaadin documentation page Server Push Configuration Reference - Vaadin Docs.
Questions, feedback, and comments are welcome here.
If you’re looking for a solution to push updates to only a specific user, there’s an example in this StackOverflow question: https://stackoverflow.com/questions/73845965/vaadin23-server-push-for-specific-other-user
The functionality as described in this documentation is not working. Adding the @Push annotation to a class that extends SpringBootServletInitializer implements AppShellConfigurator does not seem to activate PUSH even though I see all the Atmosphere output in the log on start up. To get push working I had to add vaadin.pushMode=AUTOMATIC in application.properties.
Automatic is the default for push, so the property should not be required.
The docs were recently updated, and the "extends SpringBootServletInitializer" should no longer be needed.
I stumbled across your workaround after two days of debugging why push is not working and it worked. After that I got curious why @Push of the AppShellConfigurator is not working. Cause was that it was not in a package that was scanned by @EnableVaadin.
Just a note on the documentation: Based on my tests, onDetach is not entirely reliable. It does not always fire, for example, when closing the entire browser rather than just a tab.
If you have a long-running thread that continuously checks for updates and pushes them, there are cases where the thread is never stopped, resulting in a dangling thread. While the documentation does not include an infinite loop in its example, I assume this is often the case when you need to check for updates continuously.
I will happen at session timeout by latest, with all browsers and regardless if push is on or not. With websocket connection on, one could think the UI could be closed easily when the connection is dropped, but detecting if the connection is lost due to browser close, tab close or due to network hickup (of which we want the UI to survice) is difficult.
With FF the situation is currently nasty with detach events as they only happen after session timeout. I'd rather make the more eager detach events work and accept a tiny regression risk for (badly implemente downloads)...
Anything depending on explicit events from the browser will face this situation in some cases, such as if the close happens while the user is momentarily offline or if the browser or computer crashes. That's why `onDetach` doesn't rely only on those events but is also fired at session timeout.
If you have an expensive thread running, then you could consider adding some custom timeout logic in the application so that that thread can always be closed eagerly rather than only when the session expires. But then you also need to take care of starting the thread again if the browser still comes back. At the same time, it might not be worth it since the cost of that thread might still be a rounding error compared to the memory used for the UI instance that anyways remains in memory until the session expires (unless you are fine with also closing the UI based on some other timeout logic).
Thx! That's good to know. Did not realize that when debugging because the session never timed out.