My customer uses a Vaading based application on IBM WebSphere Application Server and has a problem with a memory leak. When I open the heap dump using Eclipse MAT, I see a lot of user session records each is about 6 MB! The majority of data in memory is a big HashMap (5 Mb) with about 700 entries. Each entry contains only a couple of com.vaadin.data.util.BeanItem instances. User’s data is only 1 Mb (it is a not good too, I understand, but it is just about only 1/6 of a session record). How to reduce the Vaadin user session memory overhead, because it is not normal when framework’s internal objects eat 5/6 of user session memory.
Sounds like you are dumping large collection to BeanItemContaner and thus keeping it in session memory. When you have large amount of data you should not store it in memory. And definitely not for each session separately.
The BeanItem(Container) in Vaadin is not optimised that well for huge data sets. Most often you don’t need all the features from it so you can switch to use e.g. ListContainer from an extension library called
Viritin (which you’ll want for pretty much each and every project anyways ). It has much much less overhead and in basic tests there is about tenfold difference in the memory consumption when listing the stuff to Table component. I’d guess that by that change alone your memory consumption could drop to acceptable level (depending on your app/usage of course).
And if there is a really large data set you want to show, you naturally need to do some sort of paging like you would do with any other UI frameworks. As Vaadin Table/Grid support lazy loading from server to client, it is often tempting to continue the lazy loading chain all the way to the data source (and not waste the memory of the server). How to do it depends a bit about your case, but without further investigation I can suggest to try MTable component (from the very same Viritin add-on) which has really simple interfaces to implement efficient lazy loading solutions.
A good introduction to the topic is in our recent XRebel webinar. No need to watch it totally, but check out the part starting from about 18m:
). It has much much less overhead and in basic tests there is about tenfold difference in the memory consumption when listing the stuff to Table component. I’d guess that by that change alone your memory consumption could drop to acceptable level (depending on your app/usage of course).