Scaling with Vaadin and WildFly Webinar

By: vaadinofficial

8   0   3009

Uploaded on 09/08/2014

Join Arun Gupta from the RedHat and Matti Tahvonen from Vaadin for a Webinar on how to scale Vaadin applications easily using WildFly application server. You'll learn what to keep in mind while designing scalable applications and how to prove they really do scale. At the end of the webinar we'll answer some questions about the topic raised before in this sign up or during the webinar.

Comments (4):

By anonymous    2017-09-20

Yes, your project may be a good fit for a Vaadin app.


Scalability can be an issue with Vaadin as your entire app lives on the server, with only a representation of the UI widgets on the client. All your business logic and data structures live on the server, not the client. So a Vaadin app can eat up memory and CPU usage on the server.

Whenever possible, cache results on the server, and share data amongst the users’ sessions. Most of the UI widgets cannot be shared, as they have state that changes per user. But you may be able to share your backing data.

Look at this two resources about scalability in Vaadin. Vaadin certainly can scale. The Vaadin company has made simulations with 11,000 simultaneous clients. See:

See my Answer on a similar Question for some discussion of when to consider Vaadin.


Threads may be very useful.

Java now offers some powerful yet simple support for threading. If you can perform chunks of your computation over time, then do so on threads.

Vaadin has built-in support for updating the user-interface from a background thread(s), similar to Swing’s SwingWorker. The UI object (all your content in a browser window/tab) offers the access method for scheduling a Runnable to update widgets. Something like this:

    new Runnable() {
        public void run() {
            // Update widgets here. 
            // Change Label text, TextField contents, and so on.
            // Show results of your computation (interim or final).
);  // Or use Lambda syntax in Java 8.

You definitely want to avoid those long computations within the user’s UI thread. At the very least, it will lock up the UI resulting in the user’s frustration and possibly thinking the app has crashed. At the worst, the session may time out as you mentioned. Just as with Swing, the solution is to do the busy work on a background thread, then schedule updates to be done on the user-interface.

Spinning Wheel

If your app has no other usefulness until the computation is complete, then you can display a spinning wheel indicator. Use the Progress Bar widget in "Indeterminate" mode. See demo of Progress Bar, click Gear icon to check the "Indeterminate" mode on "Sample" tab. Use the "Theme" tab to see each different wheel style for Valo and Reindeer themes.

ProgressBar in Indeterminate mode, screen shot

If you can quantify the progress of your computation as a number between 0.0f and 1.0f, you can use a Progress Bar with "Indeterminate" property turned off.

ProgressBar not in Indeterminate mode, screen shot


Background processing with threads is easier than ever now in Vaadin 7. Push technology is now built in to Vaadin.

See this chapter in The Book Of Vaadin.

Without Push, updates to the UI would only be delivered to the browser after a user’s action such as a button click (unless you pulled some tricks).

In Vaadin 7, you merely add the @Push annotation to your main class. Then the bundled Atmosphere library takes over. Atmosphere takes care of automatically trying WebSocket connections to deliver the updates. If WebSockets is not available, it falls back to other approaches such as polling.

Atmosphere has been a very successful project, used in many products. So for the most part it works very well. Be aware though that Push and especially WebSocket is relatively new technology with many changes in specs, implementations, servers, and browsers. There may be some bumps along this new road.

Working Examples of Push

I have provided the source code for two entire example projects of using Push with Vaadin. See this Question for a simple one. See this other Question for more depth.


Regarding your specific question:

If I use polling wouldn't that be too much workload on the server considering many users might launch calculations at the same time?

Various kinds of polling are used all the time on the web in Push technology. I imagine you are seeing it right now (if using a web browser) as StackOverflow updates your "Recent inbox messages" & "Recent achievments" badges up at the top of this page.

Polling is by definition inefficient. The browser will be making calls to the server that will often be fruitless with no fresh data yet produced on the server. And an HTTP connection is relatively expensive to establish.

But the overhead and expense is not inordinate. Polling works, probably happening billions of times a day around the Internet.

With HTTP/2 arriving, these calls will become more efficient with less overhead.

The optimal solution would be for the server to notify the client when fresh data has become ready. This is the raison d’être of WebSocket technology, for the browser and server to keep open a live network connection to allow bidirectional communication at any time. As I said above, the Atmosphere library automatically tries WebSocket and falls back to Polling if need be.

So, the answer to your question, is "No, not too much workload for server.". Polling is a practical solution in common use for keeping a web client up-to-date with server-side events.

Updating UI

I'm not savvy about actors.

UPDATE: Vaadin 8 has a new data model that is much simpler, discarding the Container and Item constructs shown below to basically use POJOs by leveraging modern Java syntax and generics.

But I can explain that Vaadin comes with its own data model. Behind all the UI widgets is a backing data structure. This structure is built on top of Vaadin-defined "properties", as Java lacks its own good property support.

When you modify that backing data, the widgets are automatically notified and update their display. I presume that your actors would be the triggering device for updating that backing data.

The Vaadin data model is explained thoroughly in The Book Of Vaadin.

enter image description here

enter image description here

Multi-module Project

If you want to keep your current back-end project separate and independent from your Vaadin UI project, you can.

The new Maven archetypes provided by the Vaadin company support the option of multi-module development. So you can continue development of your backend as an independent project, yet plug it into your Vaadin project as another module.

See this recent YouTube webinar, Crash Course to Official Vaadin Maven Archetypes Webinar, by a couple of people on the Vaadin team.

When learning Vaadin, I suggest you start with a throwaway project using the simple single-module archetype. Unless you are already a Maven maven, in which case, go for it.


Two options for charting: use Vaadin Charts product or roll your own.

Vaadin Charts

The Vaadin company offers a commercial product (fee required), Vaadin Charts, for producing interactive nicely-rendered charts in a Vaadin app. Try the live demo.

Vaadin Charts is basically a Vaadin (pure Java) wrapper around the highly successful JavaScript charting library project, HighCharts. So Vaadin Charts is well-worn and very advanced in its charting, as it is not brand-new.

Using Vaadin Charts means you can prepare all your data in pure Java, and package it up for display in the charts using pure Java. Vaadin takes care of getting that data to the client. Then the built-in HighCharts library automatically performs the rendering of the chart’s graphics on the user’s machines using the JavaScript engine in the user’s browser. So your server is not burdened with that rendering chore. And you are not shipping images across the network or Internet.

I am using Vaadin Charts (2.1 beta) in my own project. I highly recommend it.

My only disappointment has been the limitation of allowing only a single time zone to be applied to date-time values in my charts. All the users must share a single time zone’s representation of time zones. This is due to the fact that Highcharts is actually rendering the charts, the rendering is built in JavaScript, and JavaScript has lousy date-time support (no Joda-Time or java.time equivalents in JavaScript). You may be able to hack around this limitation with a couple of included crude time adjustment functions, but it may make your brain hurt.

The Vaadin company offers a free trial.

You might want to watch this webinar on YouTube with some of the Vaadin team talking to the boss from the Highcharts company about their combined efforts.

Roll Your Own

If you are already generating images or svg files to represent your charts, you could generate those server-side and deliver them to the client within your Vaadin app.

If you are using JavaScript to generate the images, you could conceivably build your own Vaadin add-on. You would need to learn about GWT and other technical matters, so there would be a significant learning curve and effort. See this chapter of The Book Of Vaadin. Basically, you would be creating the equivalent of the Vaadin Charts product.

Original Thread

By anonymous    2017-09-20


Vaadin in an amazingly good tool for building interactive desktop-style web apps developed in pure Java and delivered via regular web browsers.


Vaadin 6, 7, and 8 apps run entirely on the server-side. The JavaScript library automatically installed by Vaadin into the user’s browser window simply:

  • Draws on-screen whatever the server-side app tells it to.
  • Feeds user actions (clicking, typing, and so on) back to the server for the app to consider and respond.

So there is no "logical validation on the client side" or "html5 validation", at least not from the Vaadin app developer’s point of view. The Vaadin framework may do so under-the-covers in its internal implementation, but that is none of my concern as a Vaadin app developer. That’s the core benefit of Vaadin: I don't care how Vaadin gets my forms onto the user’s screen. As a Vaadin app developer, I am not writing any JavaScript, HTML, DOM, CSS, or AJAX. Just pure Java.

The style is similar to Swing: Instantiate a layout (a form), add labels, add buttons, add fields, add other widgets. Attach validators as needed. Nest additional layouts, for complicated forms. All of that executes in memory on the server-side, all in pure Java. Finally tell the layout to show itself. Poof, like magic, Vaadin tells the browser to display a likeness of that form.

If you want to develop desktop-style business-style apps that happen to be deployed through a web browser, Vaadin is a wonderful tool.


Trade-offs include:

  • Lots of memory and CPU usage on the server-side.
  • Giving up control over the HTML/CSS/JavaScript.


Your web app lives on the server, not the client. All your business logic, the users’ entered data, the internal representation of all the users’s forms such as row items in a table, all this lives on the server. Multiply that by number of users. This means a Vaadin app can demand much memory and CPU usage.

That may limit scaling up. But given 64-bit Java, multiple gigs of memory, and multiple cores on even the lowliest of machines such as a Mac mini, scaling-up is likely an issue only for the largest/busiest of apps.

And even in those rarer of large/busy app there may be ways to handle scaling in Vaadin. All of the app lives in a Servlet Session. Some web infrastructure allows such session state to be moved between servers or even persisted out to storage to be picked up by other servers.

Or your app may scale well. Simulations with 11,000 simultaneous clients have been done. See:

Control Over HTML, CSS, JavaScript

If your team is more comfortable or experienced with conventional web app architectures, then Vaadin may not be for you. In Vaadin you write your app entirely in pure Java, and Vaadin translates that to HTML, CSS, and JavaScript automagically.

You can tweak the CSS a bit. And even without touching CSS, Vaadin’s "themes" (Valo, Reindeer) give you much control over colors, sizes, and fonts if you wish to override the defaults. But know that Vaadin is in the “driver’s seat” in generating the HTML & CSS; you are just passenger who is allowed a small bit of “backseat-driving”.

If your goal is something other than developing desktop-style apps, if you want to take full control of the HTML/CSS, then Vaadin may not be for you.


Vaadin 8 released

On Feb 22, 2017, Vaadin 8 was released. Biggest enhancement is re-written data model and data binding API utilizing modern Java features, such as generics with type parameters and lambda expressions. Also, more efficient with memory and CPU.

Vaadin 7 released.

While largely the same architecture as Vaadin 6, 7 is better than ever. See: What's New.

Original Thread

Submit Your Video

If you have some great dev videos to share, please fill out this form.