Vaadin allows you to easily build interactive web applications by working with a familiar server-side architecture. The rich component model is usually driven by session state that is preserved for each instance of a Vaadin application. Each user and browser window will create such a new instance, which can make the size of your server-side sessions grow very quickly if you refer to too much data from your UI or accidentally create a memory leak.
Thanks to XRebel, it’s very easy to see how much each Vaadin instance contributes to the global server-session size. Let’s take a look at the standard Vaadin dashboard demo application, which you can obtain yourself from GitHub: https://github.com/vaadin/dashboard-demo/tree/f7813fccc453da30c6ef51044e8a3533ebd7c5a8. Note that this isn’t really a typical production-level application, but an example that showcases Vaadin features quickly and clearly. Each user will get his own set of demo data, making the resulting measurements useful to work with for this article.
After building the
quicktickets-dashboard-1.0.1.war package and putting it in the Tomcat
webapps directory, all we have to do is start up Tomcat so that XRebel can analyze the application’s behavior in real-time, for example like this:
CATALINA_OPTS="-javaagent:xrebel-1.1.0/xrebel.jar" ./bin/catalina.sh start
When we visit the demo application, we instantly see the XRebel toolbar that indicates how much size our session is taking for this initial visit. (334.4 KiB)
Things get much more interesting when we reload the application by refreshing the browser page. XRebel immediately detects that the global session size exceeded the configured threshold of 500 KiB and alerts us. This new request added another 334.9 KiB to the session, bringing it all to way up to 669.3 KiB!
Let’s now dig in and take a look at where this session data is being consumed. When you click on the XRebel session icon, a dialog opens that shows exactly what was in the session at the time of the measurement. The main
VaadinSession instance has a series of entries for internal book-keeping, with the most interesting one at the top:
uls. It clearly shows that there are two instances active of the Vaadin application, each time starting at the
When we drill deeper into the last
DashboardUI instance, it becomes obvious what the culprit is for the increase in session size: the
dataProvider is eating up the bulk of the data through its
This is confirmed by the code, where the
DashboardUI has a
dataProvider field, which in turn has a
transactions field. This is then populated with 1000 entries of data to display, creating the session increase that XRebel detected.
Granted, in this case the example is a bit artificial since the data is generated on the fly. However, in reality, this could very well be the result of database queries that causes the Vaadin in-memory data container to become just as heavy. You’ll immediately see that you need to limit the results of your query or switch to a lazy loading container implementation like LazyQueryContainer.
Actually, Vaadin themselves took the opportunity to inspect their demo application with XRebel and improved the latest version. Instead of using an IndexedContainer for the transactions, the new version is now relying on a FilterableListContainer add-on, dramatically reducing the session bloat.
As you can see, XRebel makes it very easy to constantly keep a hold on the session during development. This makes you as a developer immediately aware of the footprint you’re introducing, allowing you to intervene at the same time as the development of the feature that’s increasing the session size.