Possible memory leak??

General
1

Hello!

I am new to Vaadin. I came across OutOfMemoryError (heap space).
I have basic application with only one window that has 3 labels and 2 inputs (login screen). Vaadin is in production mode.

I launched this under tomcat with 32mb heap.

Then I launched 2 threads each runs the following code 5 times a second:
<…>
while (true) {
URL url = new URL(“http://localhost:8080/”);

    HttpURLConnection conn = (HttpURLConnection)url.openConnection();

    conn.connect();

    System.out.println("Connected [httpResCode=" + conn.getResponseCode() + ']

');

    conn.disconnect();

   Thread.sleep(200)

}
<…>
This code makes vaadin application to create login window again and again. And my tomcat runs out of memory in several minutes (threads made only less than 2000 requests). I can’t say that this is a huge load. There are approximately 10 requests per second.

I profiled tomcat with visual vm and saw that there are a lot of Vaadin UI components that are never GCed (Labels, Buttons, etc).

As far as I can see all instantiated components go to maps:
com.vaadin.terminal.gwt.server.AbstractCommunicationManager.idPaintableMap
com.vaadin.terminal.gwt.server.AbstractCommunicationManager.paintableIdMap

And they are never removed from… app runs out of memory first. I have default session timeout.

Can anyone tell me what is wrong here? Do I miss some critical setup options?
Where can I find full information on component lifecycle if any?

Any help on this will be appreciated.

Thanks.

2

You really seem to be trying to look for limits… but this testing methodology tells very little about real-world performance and scalability characteristics for anything but a DoS-attack attempt, as it ignores most aspects of the life cycle of a Vaadin application - sessions, cached static resources, XHR UIDL requests interacting with existing application instances (rather than initializing a new application for each request) etc.

Also, 32 MB heap is very small, as there is some common overhead. On top of that, each Vaadin session can be e.g. 100-200 kB in size depending on the application - more if unnecessarily keeping large containers or other data in memory but probably quite a bit less in your case. I am not sure what is the default session expiry time and whether you have any sessions expiring, but with 2000 sessions and the fixed overhead, you might run into the heap size limit. If you are implementing a real-world application, 32 MB heap is completely unrealistic and over-emphasizes fixed and slowly growing overhead, so testing with a significantly larger heap should yield more realistic results.

As for the maps you mentioned, they are cleaned of components of all closed (either by session expiration or explicitly) applications when there is any real UIDL request from any executing Vaadin application in a browser. If no session is actually executing JavaScript and making such requests, the maps can indeed grow quite a bit.

For the kind of scalability that is achievable (with appropriate tweaking when going to the enormous scale of the example), see e.g.
these scalability slides
.

While Vaadin is not an ideal tool for large web sites, it is quite scalable when implementing interactive web applications. In such use, even very large numbers of users of real-world applications can usually be supported on a single server with a few gigabytes of memory for the heap.

3

After launch and rendering single request to browser tomcat takes approximately 6 MB heap (as far as I can understand this is “common overhead”).
The rest is taken after subsequent requests made by the threads.

By default tomcat has 30 min session and unlimited active sessions count.

If I limit max sessions to 100 (or any CERTAIN positive value ) it does not run out of memory. hm-m-m-m… how many vaadin users have forgotten to limit active sessions count and may be a potential victim of such primitive attack? =) It seems this is worth mentioning in documentation and your book (I tried to search on this but found nothing).

Btw, I know that there are no production systems working with 32MB heap, that was just a test…

Anyway, thanks for your quick and responsive support.