Out of Memory Because Error Compressed Class Space

Hello All;

I am using Spring MVC version 5.3.29 with Hibernate version 5.6.15.Final, and I am getting Out of Memory Because Error Compressed Class Space although I set the size to be 3g using the argument -XX:CompressedClassSpaceSize=3g. In order to detect where is the memory leak happening and which class is keep loaded again and again, so I added the following argument for JVM: -Xlog:class+load=info  and we discovered that there are some classes which are hibernate model classes (classes defined to be mapped to the tables) are loaded and loaded again (based on the below obtained tomcat log). Please note that we are using session.createNativeQuery recently and some queries are still session.createSQLQuery.

In the hibernate model classes (that I created), I imported the following:

import javax.persistence.Column; import javax.persistence.Entity; import javax.persistence.Id; import javax.persistence.Table;

I am closing the sessions using session.flush(), session.clear(), session.close() and session.getSessionFactory().close().
Moreover, I am using the below hibernate dependency:

<dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-core</artifactId> <version>${hibernate.version}</version> <exclusions>         <exclusion>           <groupId>xml-apis</groupId>             <artifactId>xml-apis</artifactId>         </exclusion>     </exclusions> </dependency>

Please see the below results of the class-load logs which contains "__JVM_DefineClass__":

Nov 09 20:12:23 telkom-ProLiant-DL380-Gen10 tomcat9[81936]: [668.329s][info   ][class,load  ] com.aliat.alm.models.ArPartNumber$HibernateProxy$iidQB5pb source: __JVM_LookupDefineClass__ Nov 09 20:12:23 telkom-ProLiant-DL380-Gen10 tomcat9[81936]: [668.330s][info   ][class,load  ] com.aliat.alm.models.FarSerialNumber$HibernateProxy$G8DIexID source: __JVM_LookupDefineClass__ Nov 09 20:12:23 telkom-ProLiant-DL380-Gen10 tomcat9[81936]: [668.331s][info   ][class,load  ] com.aliat.alm.models.ShopsListViewAPI$HibernateProxy$eiKRMquC source: __JVM_LookupDefineClass__ Nov 09 20:12:23 telkom-ProLiant-DL380-Gen10 tomcat9[81936]: [668.333s][info   ][class,load  ] com.aliat.alm.models.DuctAuxPoints$HibernateProxy$fMmiLzet source: __JVM_LookupDefineClass__ Nov 09 20:12:23 telkom-ProLiant-DL380-Gen10 tomcat9[81936]: [668.335s][info   ][class,load  ] com.aliat.alm.models.User$HibernateProxy$WAW8kJIs source: __JVM_LookupDefineClass__ Nov 09 20:12:23 telkom-ProLiant-DL380-Gen10 tomcat9[81936]: [668.341s][info   ][class,load  ] com.aliat.alm.models.DiscoveryNewItem$HibernateProxy$11yizTfT source: __JVM_LookupDefineClass__ Nov 09 20:12:23 telkom-ProLiant-DL380-Gen10 tomcat9[81936]: [668.342s][info   ][class,load  ] com.aliat.alm.models.FarPartNumber$HibernateProxy$Aey4F1T6 source: __JVM_LookupDefineClass__ Nov 09 20:12:23 telkom-ProLiant-DL380-Gen10 tomcat9[81936]: [668.344s][info   ][class,load  ] com.aliat.alm.models.Warehouse$HibernateProxy$yyLtcDuw source: __JVM_LookupDefineClass__ Nov 09 20:12:23 telkom-ProLiant-DL380-Gen10 tomcat9[81936]: [668.347s][info   ][class,load  ] com.aliat.alm.models.TroubleTickets$HibernateProxy$YlQpyJQs source: __JVM_LookupDefineClass__ Nov 09 20:12:23 telkom-ProLiant-DL380-Gen10 tomcat9[81936]: [668.348s][info   ][class,load  ] com.aliat.alm.models.AgentShops$HibernateProxy$1AbsUVKW source: __JVM_LookupDefineClass__ Nov 09 20:12:23 telkom-ProLiant-DL380-Gen10 tomcat9[81936]: [668.349s][info   ][class,load  ] com.aliat.alm.models.ShopImageAPI$HibernateProxy$PNF4HTA0 source: __JVM_LookupDefineClass__ Nov 09 20:12:23 telkom-ProLiant-DL380-Gen10 tomcat9[81936]: [668.350s][info   ][class,load  ] com.aliat.alm.models.RegionBorder$HibernateProxy$Xmg8H8Ir source: __JVM_LookupDefineClass__ Nov 09 20:12:23 telkom-ProLiant-DL380-Gen10 tomcat9[81936]: [668.352s][info   ][class,load  ] com.aliat.alm.models.NodePassive$HibernateProxy$kZO8dvzS source: __JVM_LookupDefineClass__ Nov 09 20:12:23 telkom-ProLiant-DL380-Gen10 tomcat9[81936]: [668.354s][info   ][class,load  ] com.aliat.alm.models.Duct$HibernateProxy$POOIIDK3 source: __JVM_LookupDefineClass__ Nov 09 20:12:23 telkom-ProLiant-DL380-Gen10 tomcat9[81936]: [668.356s][info   ][class,load  ] com.aliat.alm.models.SchedulerRules$HibernateProxy$8yOHOnZ2 source: __JVM_LookupDefineClass__ Nov 09 20:12:23 telkom-ProLiant-DL380-Gen10 tomcat9[81936]: [668.358s][info   ][class,load  ] com.aliat.alm.models.Mobile_Trouble_Tickets_Actions$HibernateProxy$xbUTXNIh source: __JVM_LookupDefineClass__

And ofcourse, the Compressed Class Space is keep increasing until I reach for out of memory.
Tomcat version is 9
JDK version is 17.
Operating System is Linux Ubuntu Server version 22.04.2 LTS

Appreciate the kindly help please.
Regards
Bilal

Please make sure that when you say "classes" you mean actual Classes and not instances of Classes (objects). You don't want to be compressing the wrong thing.

One thing that looks alarming to me, however, is that you're using javax.persistence classes to define your Entities but you talk about using a "session" as your persistence controller. javax.persistence  (now jakarta.persistence) defines the Java Persistence API. JPA does not use "sessions", it uses EntityManagers. The "session" is something that existed in legacy Hibernate, which is NOT JPA-compliant. I don't recommend writing anything for Hibernate's legacy ORM. It's obsolete and you should be using Hibernate JPA, instead.

In other words, I think that you are improperly mixing new and old Hibernate code and if so, it's not surprising that things don't work right.

Thank you for your help and kindly advise.

Please make sure that when you say "classes" you mean actual Classes and not instances of Classes (objects). You don't want to be compressing the wrong thing.

Actually I displayed what I see in the journal logs which is related to class-load, so based on that I said classes as it is displayed by class-load as shown in the below line (as sample of the logs):

Nov 09 20:12:23 telkom-ProLiant-DL380-Gen10 tomcat9[81936]: [668.335s][info   ][class,load  ] com.aliat.alm.models.User$HibernateProxy$WAW8kJIs source: __JVM_LookupDefineClass__

Now coming to the sessions and EntityManagers, actually when creating session, I am using:
StandardServiceRegistry, SessionFactory and session and when I need to close it, then I use session.close() and session.getSessionFactory().close(). So I am in wrong direction? Can you please put me in the right track?

Moreover, can I know why the using of sessions is causing this class loader problem which cause the out of memory because Compressed Class Space is full?

Again, I am really very thankful for your great help and advise.
Regards
Bilal

Your log messages are meaningless to me. The message formatter isn't set up to supply all the information I need and in particular the actually logger name.

In JPA, you handle persistence by obtaining an EntityManager from an EntityManagerFactory. The EntityManager serves much the same purpose as the ancient Hibernate "Session", but the two are not compatible. You should not be referring to "session" at all in a JPA application and the fact that you could even compile without "session" being flagged as undefined means I suspect that you have mixed both types of Hibernate in the same application build.

This is roughly the same thing as expecting to operate an automatic-transmission vehicle using a manual clutch and gearshift. The parts don't match and as long as that isn't fixed, there's no telling what can go wrong.