Hello, I have jsf web application. I'm using jsf 2.1.9, hibernate 4.1.4, glassfish 3.1.2, primefaces 3.4.1. The problem is, used heap size is increasing slowly and after 2-3 days, reaches max heap size. then I must restart glassfish. heap dumps:
at the beginning, i clicked all web pages in application and used heap size was 100 MB:
after 1-2 days, used heap size is increased to 300 MB (same web pages used during this time):
I took screenshot of most used classes in heap. in my web pages, I generally select some objects from database and render it. here are some beans:
By the way, I have a mistake that I'm aware; I should not perform business logic in getters, but I think it is not the main reason of my problem. I need help and some advices. I can provide more information if you need, Thanks for your helps
I spent an entire month discovering the hard way that Oracle's "cache" did not adhere to one of the fundamental concepts of cache - limiting itself to a finite size by purging older entries. In short, the cache was "bottomless" - until the heap was exhausted.
The maddening thing about this was that the condition was occurring in a batch process that took 2-3 days to run, so I had to run a multi-day test, wait for it to bomb, analyze the results, then do it all again.
At the end, I found out that this was not a "bug" in either my logic or Oracle's. The behavior, though rude was documented, though obscurely. Very obscurely. If you knew what parameters to set, you could avoid the issue.
An IDE is no substitute for an Intelligent Developer.
Joined: Oct 02, 2011
I did not enable second level cache in persistence.xml. I'm not using hibernate configuration file, here is my persistence.xml:
After Balaji Manoharan Bm's comment, I added this property too:
and it will not have any effect, we will see.
I also want to show you more things from heap dump:
In char class' instances, there are too much sql query string. I think Balaji Manoharan Bm is right, there is a problem with hibernate but where exactly ? I'm researching but it cost's to me much time.
The reason why you should not place business logic in "getters" is that the overhead is ferocious. It's common for a property-get method to be invoked six times in a single page render request. The actual number of calls isn't easily predictable, but will almost always be multiple times. Database operations are very slow. Multiplying that by 6 is cruel and unusual punishment. Which is why when I need a "get" method to make a run for the database, I do it on the first request and cache the results. And, of course, the request must have no side-effects, since every "get" call should leave the state of the backing bean in the same condition.
Aside from that, though, why are you doing a "commit" on a database fetch? "commit" is what you use to formally apply changes to the data, not inquiries. And you definitely should not be doing changes to the database in a "get" method for the reasons listed above.
Congratulations on taking the heap dump. That's like half the battle right there.
In your heap dump, look at what those hash map entries contain. That will give you a clue. I'm not sure which tool you are using to do heap dump analysis there. I use MAT and in MAT you can click on a object and see outgoing references. This allows you to see the key value pairs in the hash map entry. Also, if you look at inbound references, it will tell you which hash map is holding that entry and which of your classes is holding that hash map.. You tool mig have some way of traversing the object graph that will give you more info.