Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
Detach Table necessary for allowing the garbage collector to clean up?
I'm currently facing a hard issue that will soon, if I can't do something about it, stop my vaadin project.
I'm having hard memory issues after deploying my vaadin application on either a glassfish or a tomcat server (memory problem occures on both of them).
I'm analyzing documents and am building up XML representations of them (using JAXB), going through this xml documents I'm generating the table output which shows e.g. one sentence on each row.
After every upload of a text or pdf file, which shows the table after a successfull upload, I can see how the memory of my server is increasing.
My assumption is that the memory keeps the uploaded documents and doesn't let the garbage collector clean them up. MIGHT it be possible that this happens because I doesn't specifically detach the table when clicking on the back button (which simply changes the view)?
This would somehow make sense to me since the table needs access on the xml-document during a scroll proccess for printing out more sentences. When now the table never knows that it is not needed anymore, the garbage collector could never know that he can clean this memory up. Am I right?
Also: The Vaadin API speaks in the documentation of the "unregisterComponent"-Method of
... The component needs to be detached from its parent and if it is a field, it needs to be detached from its property data source in order to allow garbage collection to take care of removing the unused component from memory. ...
My guess would be that I now need to add table.detach() everywhere a listener is going to change the view of my application.
Can you please tell me your oppinion and let me know what you think about this? I'm in trouble currently and really need help, because I otherwise probably need to stop my project, which would be really sad.
Thanks a lot for every post!
The memory leak can be also in somewhere else. How are you changing the views (the back button click)? Are you holding references to the documents somewhere else? How are you populating the Table, what container are you using? A bit more details and/or code is needed.
Just wanted to point out that increasing memory doesn't necessarily mean there's a leak. It may be that the server just waits to do a garbage collection until it's needed. I was doing some memory leak testing with GlassFish and class loaders a couple months ago and I'd see the memory usage keep creeping up and up. After 15 minutes or so (I can't remember the details now) I'd see it drop back to the baseline. Then it would repeat.
So while you may actually have a memory leak, you should do a longevity test to make sure there's really a problem.