I am building my applicaiton and it contains lot of requests from Database and i am using a lot of BeanItemContainers as well.
My application gives a permgen space after sometime each day.
Any suggestions
I am building my applicaiton and it contains lot of requests from Database and i am using a lot of BeanItemContainers as well.
My application gives a permgen space after sometime each day.
Any suggestions
My first guess is that you load a lot of objects to heap, but do not release them. Try some profiler to see what objects consume your heap.
I have too many Bean objects and pictures and trees which i am using. Actually i have 5 different modules running inside the same window. It is an administration application which basically contains data entry screens, searching and also displaying all the records for customers, products, users etc. Also with each products there is a detail window and a picture(Embedded).
Is that the reason why i am getting this error?
I am a bit new to the development environment so can you give me some tips as to how do i release objects?
Thank you
Maybe you could design your beans to be lazy - only load heavy properties - like images - on demand and use weak references to them to get them out of the heap when they are not used anymore.
If the number of beans in container is excessive, you may be forced to create a lazy container that only keeps the actively used beans in memory instead of using BeanItemContainer.
Also make sure that you do not keep any static references to beans/containers after your user have logged out (application.close()).
‘After some time’ makes it sound like a memory leak of some sort. Please make sure you’re not keeping references to objects you’re no longer using.
Specifically, if your application uses native windows (a.k.a browser windows/tabs) you’ll want to make sure you clean up when the user closes the window or navigates away from the application - or presses reload, for that matter. You’ll get a close-event when this happens, and if you do not want to re-use the window instance, you should remove it. Note that this only applies if you use windowing - applications w/ a single (main) window will not leak in this manner.
Of course it’s worth to note that every application has some individual memory requirements, which grow with the number of simultaneous users - the memory available to the application must of course be sufficient to support the application to begin with, even if there are no “memory leaks”.
Best Regards,
Marc
Edit: Also a question: does the error occur after you have been using the application alone for some time (i.e during development), or after running it for a while with multiple users?
It gives me the error when i use the application in a single user environment but it takes a while to generate this error.
But yesterday, we tried it on a multi user environment and saw that it could not even support two browser windows at one time. It gave java heap space error on one machine.
My application is a one with an accordion controlling navigation to different parts of the application which are products(4 types), customers, invoices, users etc. And each of these modules contain searching, displaying, and adding more records/. I use bean item container for this purpose and some modules contain records above 500 too. This number would obviously increase over a period of time.
According to my knowledge when i close an application, the numerous objects are collected by the garbage collector. Am i wrong in saying this?
You need to document yourself on the memory management parameters for Java in general. The default parameters are very small and often completely inappropriate for Web applications. You need to read the documentation on the mx and ms parameters to Java, and on how to change them when invoking your Web Container.
For normal memory problems, you would increase the heap size, using the Java VM parameters. The parameters will look like this
-Xmx384M -Xms384M
If using Tomcat, you will need to change your catalina.bat file
set CATALINA_OPTS=“-Xms384M -Xmx384M”
Now the “permgen” is not the same kind of memory heap. It usually blows up when you have many classes, or use dynamic classloaders to load a large number of classes, or do a lot of recompiling / reloading. See the following for an explanation
In order to increase Permgen space, you have to use another parameter
-XX:PermSize=64m
(where you see the smile there should be two characters, a : followed by a capital P – see the article)
You should add that to your options. From memory, the initial size for the heap is 64MB and the permgen tops out at 16M,
Note also that PermGen is specific to Sun’s Virtual Machines. If you use another VM from BEA for example there may not even be a PermGen space to bug you.
Hi,
I am still getting the PermGen Space errors.
I have increased the heap size to 128M. I ran the NET BEANS 6.0 profiler as i am using this IDE. I had the following observations:
Note:
My application is an admin application and is somewhat similar to the Address Book application provided in Vaadin Demo.
And i can get help from only you people because i live in Jaipur, INDIA and probably i am the lone person using Vaddin here.
(A summary from a Skype chat)
The problem was apparently the well-known problem that as Eclipse reloads the application in the Tomcat running under Eclipse, the reloading of the classes by the class loader doesn’t free the permgen space used by class metadata.
The solution was to add the following parameters to the VM arguments in Tomcat’s launch configuration:
-Xms256 -XmX512 -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=512m
Well, the above memory size parameters may be “largeish” and much less memory could be sufficient.
In a similar case, the problem crashes Eclipse, not the application (or Tomcat). In that case, the above parameters should be given to Eclipse when starting it.
I tried out all the parameters, but eclipse wouldn’t start. I just crashed with a fatal error: -1. After removing the -XX:MaxPermSize=512m parameter it started up again. Just wanted to point out that, if someone else have had similar problems.