Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
Tomcat7 performance with out of memory issue
we develop a document management systems with Vaadin, the architecture of the application is distributed one app server e multiple mysql databases. We have 16 sites one for each branch unit. So, we have 16 databases and only one tomcat7 container.
The maximum number of users concurrent are 50, we use static containers for some table data that are static for all sessions in same site. We are dealing with a memory issue in tomcat event when no users connected, we expected that garbage collection handle non referenced objects.
We are working with JPA eclipselink, beancontainer with at the most 100 jpa entities. We call clear and close in each entitymanager created.
There are any suggestion for how to solve this memory increase? After 3 days we have to do restart to tomcat service to release memory.
Thanks in advance
This looks like a textbook example of a memory leak (likely nothing to do with Tomcat or Vaadin). YourKit is good, but if you need to use a free tool, the VisualVM tool that comes free from Oracle is usually quite sufficient. Note that you will need to add -Xshare:off to your tomcat options (see http://visualvm.java.net/gettingstarted.html for how to get started).
For hunting down memory leaks, you would force a garbage collection and immediately after take a heap dump. You will then see a bunch of objects that should not be there. They are usually attached to a static or singleton. In general, the first thing to look at is all your static objects -- you should not have any, except for the purpose of creating a singleton. And when you have a singleton, you have a global variable. If it references an object, that object will stay in memory forever, unless the singleton sets it free by making all references be null. Typical bugs is a simple hashset cache held by a singleton. Unless you set references to null, it will grow forever (implementing a fixed size cache is one way to force things to be set to null).
Another useful free tool is psi-probe ; it is useful to check connection pools and memory remotely.
Finally, set the HeapDumpOnMemoryError and verbose:gc options (see sections B1.2 and B2.2 in document http://www.oracle.com/technetwork/java/javase/index-137495.html