Spring Data Rest gives GC overhead exceeded

Question

EDITED

There are 2 entities User and RefSecQuestion linked as below -

Inside User : This was changed to EAGER to Work around Bug

@ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "question", nullable = false)
    public RefSecQuestion getRefSecQuestion() {
        return this.refSecQuestion;
}

Inside RefSecQuestion :

@OneToMany(fetch = FetchType.LAZY, mappedBy = "refSecQuestion")
public Set<User> getUsers() {
    return this.users;
}

Visiting URL - /api/refSecQuestions or /api/users/2/refSecQuestions give this error -

 11:25:14,320 WARN LoadContexts.cleanup():115 - HHH000100: Fail-safe cleanup (collections) : org.hibernate.engine.loading.internal.CollectionLoadContext@32f6b537<rs=org.apache.commons.dbcp2.DelegatingResultSet@72b935ef>
2014-10-19 11:25:14.522:WARN:oejs.ServletHandler:qtp1075697729-17: 
org.springframework.web.util.NestedServletException: Handler processing failed; nested exception is java.lang.OutOfMemoryError: GC overhead limit exceeded
    at org.springframework.web.servlet.DispatcherServlet.triggerAfterCompletionWithError(DispatcherServlet.java:1280)
    at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:958)
    at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:870)
    at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:961)
    at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:852)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
    at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:837)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:769)
    at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
    at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
    at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
    at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1125)
    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
    at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
    at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1059)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
    at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
    at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
    at org.eclipse.jetty.server.Server.handle(Server.java:497)
    at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
    at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:248)
    at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:610)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:539)
    at java.lang.Thread.run(Thread.java:745)
Caused by: 
java.lang.OutOfMemoryError: GC overhead limit exceeded
    at org.hibernate.internal.AbstractSessionImpl.generateEntityKey(AbstractSessionImpl.java:327)
    at org.hibernate.engine.internal.StatefulPersistenceContext.getCollectionOwner(StatefulPersistenceContext.java:694)
    at org.hibernate.loader.plan.exec.process.internal.CollectionReferenceInitializerImpl.findCollectionOwner(CollectionReferenceInitializerImpl.java:141)
    at org.hibernate.loader.plan.exec.process.internal.CollectionReferenceInitializerImpl.finishUpRow(CollectionReferenceInitializerImpl.java:87)
    at org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.readRow(AbstractRowReader.java:125)
    at org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:129)
    at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138)
    at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102)
    at org.hibernate.loader.collection.plan.AbstractLoadPlanBasedCollectionInitializer.initialize(AbstractLoadPlanBasedCollectionInitializer.java:100)
    at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:693)
    at org.hibernate.event.internal.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:92)
    at org.hibernate.internal.SessionImpl.initializeCollection(SessionImpl.java:1897)
    at org.hibernate.collection.internal.AbstractPersistentCollection$4.doWork(AbstractPersistentCollection.java:558)
    at org.hibernate.collection.internal.AbstractPersistentCollection.withTemporarySessionIfNeeded(AbstractPersistentCollection.java:260)
    at org.hibernate.collection.internal.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:554)
    at org.hibernate.collection.internal.AbstractPersistentCollection.read(AbstractPersistentCollection.java:142)
    at org.hibernate.collection.internal.AbstractPersistentCollection$1.doWork(AbstractPersistentCollection.java:171)
    at org.hibernate.collection.internal.AbstractPersistentCollection$1.doWork(AbstractPersistentCollection.java:156)
    at org.hibernate.collection.internal.AbstractPersistentCollection.withTemporarySessionIfNeeded(AbstractPersistentCollection.java:260)
    at org.hibernate.collection.internal.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:155)
    at org.hibernate.collection.internal.PersistentSet.isEmpty(PersistentSet.java:166)
    at org.springframework.data.rest.webmvc.PersistentEntityResourceAssembler$1.doWithAssociation(PersistentEntityResourceAssembler.java:159)
    at org.springframework.data.mapping.model.BasicPersistentEntity.doWithAssociations(BasicPersistentEntity.java:337)
    at org.springframework.data.rest.webmvc.PersistentEntityResourceAssembler.getEmbeddedResources(PersistentEntityResourceAssembler.java:128)
    at org.springframework.data.rest.webmvc.PersistentEntityResourceAssembler.wrap(PersistentEntityResourceAssembler.java:106)
    at org.springframework.data.rest.webmvc.PersistentEntityResourceAssembler.toResource(PersistentEntityResourceAssembler.java:84)
    at org.springframework.data.rest.webmvc.RepositoryPropertyReferenceController$1.apply(RepositoryPropertyReferenceController.java:141)
    at org.springframework.data.rest.webmvc.RepositoryPropertyReferenceController$1.apply(RepositoryPropertyReferenceController.java:110)
    at org.springframework.data.rest.webmvc.RepositoryPropertyReferenceController.doWithReferencedProperty(RepositoryPropertyReferenceController.java:464)
    at org.springframework.data.rest.webmvc.RepositoryPropertyReferenceController.followPropertyReference(RepositoryPropertyReferenceController.java:148)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

This question appears to be off-topic because it is a bug report, not a question. — , Oct 19 '14 at 09:10
Is there a workaround for avoiding this GC error in Spring data Rest and I am not entirely sure if GC overrun is directly related to that bug ? — fortm, Oct 19 '14 at 09:12
No idea, but you are presenting two separate issues (serializable ID issues and GC issue) without offering any reason to think they are related. If you are specifically concerned with the GC issue then consider focusing your question on that, or else connecting it to the serializable ID issue. — , Oct 19 '14 at 09:20
User model itself has about 20 @OneToMany relations as well with other table which is Fetch Type LAZY, just for facts. I don't however think that should matter for URL to RefSecQuestion which is only ManyToOne relation in User — fortm, Oct 19 '14 at 09:38
related link : http://stackoverflow.com/questions/26451920/pagination-in-spring-data-rest-for-nested-resources — fortm, Oct 19 '14 at 17:28

Philippe Marschall · Accepted Answer · 2014-10-19T10:27:27.307

1

GC overhead limit exceeded means you run out of memory when using the CMS garbage collector. This can either be due to a memory leak or your application simply having a larger live dataset than your VM options allow. To figure out the issue use

-XX:+HeapDumpOnOutOfMemoryError

and possibly -XX:HeapDumpPath (check Java HotSpot VM Options for more information). Then run a tool like Eclipse MAT to figure out what the issue is. There are also several commercial tools available like Plumbr.

edited Oct 19 '14 at 10:27

answered Oct 19 '14 at 10:22

Philippe Marschall

4,452
1
34
52

i found that when the resultset of Spring Data REST is very big, this is happening leading to OutOfMemory. However, all my repositories are extending JPARepository. I don't understand how default pagination is not happening which should limit first page result to 20 only – fortm Oct 19 '14 at 15:10
Why do you expect pagination to happen? Can you post your repository? – Philippe Marschall Oct 19 '14 at 19:30
added the repositories in related link http://stackoverflow.com/questions/26451920/pagination-in-spring-data-rest-for-nested-resources – fortm Oct 20 '14 at 02:55

Spring Data Rest gives GC overhead exceeded

1 Answers1