Is using @Push on a UI that handles all requests a bad idea?

Hello and thank you in advance. I am someone who knows very little about Vaadin. Can anyone help me with a question about the @Push annotation?

The application I work on has one main UI. In order to stream long running reports to the user it was annotated with @Push. A runnable will run and open a stream when done and the application has an asynchronous response like it should. All of the rest of the app works like it should also. However, I wonder if it is a bad idea.

Here is the VaadinServlet pseudo code:

@WebServlet(name = "default", urlPatterns = {"/*"}, asyncSupported = true)
@VaadinServletConfiguration(productionMode = false, ui = MainUI.class)
public final class CzrmisVaadinServlet extends VaadinServlet implements SessionInitListener {
  ... service override
  ... servletInitialized override
  ... sessionInit override

Here is the main UI psuedo code:

public final class MainUI extends UI
  @Override protected void init(final VaadinRequest request) {
    ... //some stuff like login logic here

Here is some pseudo code for the runnable:

public class CreateReport extends Thread {
  public void run() { 
    File report = createReport();
    MainUI.getCurrent().access(() -> {
      final FileStreamResource streamResource = new FileStreamResource(report);
      Page.getCurrent().open(streamResource, "Excel Export", 800, 800, BorderStyle.NONE);

Unless you have experienced any issues with @Push enabled, I would leave it there. In addition to providing duplex communication, the websocket also reduces the latency for the user as they don’t need to do TCP handshakes and send headers for every request. Vaadin 7.6 introduced some nice improvements to websocket communication, like reconnecting broken sockets.


Just to verify, the entire application is now using web sockets for every request?

Yes, as long as the client supports it and there are no proxies etc in between that don’t support web sockets. In case Vaadin is unable to establish a web socket, it will fall back on a series of alternatives to make sure that the user gets a working app

You can check this in the network inspector in your browser if you want.