aspose file tools*
The moose likes Tomcat and the fly likes java.lang.OutOfMemoryError: Java heap space Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Products » Tomcat
Bookmark "java.lang.OutOfMemoryError: Java heap space" Watch "java.lang.OutOfMemoryError: Java heap space" New topic
Author

java.lang.OutOfMemoryError: Java heap space

Eli Wood
Ranch Hand

Joined: Sep 04, 2008
Posts: 37

One of our applications hosted on Tomcat 6.0.18 has started throwing these errors. From what I've read, this is usually solved by patching memory leaks or increasing the amount of heap space available to Tomcat on startup.

The problem is that I have already configured Tomcat to have 1 GB of memory available and this application will cause these errors to be thrown when less than 300 MB is being used. Also, the errors are thrown in a couple of seconds, which doesn't seem like it'd be enough time for this server to use up all that memory.

I have monitored Tomcat's memory usage on the server with Task Manager while these errors are happening and I can tell the memory usage doesn't change much. Any clue what might be happening?

I've included two of the errors below... I'm not sure how helpful this will be:

Jun 16, 2009 11:58:21 AM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet toolservlet threw exception
java.lang.OutOfMemoryError: Java heap space
at com.esri.sde.sdk.client.s$a_.o(Unknown Source)
at com.esri.sde.sdk.client.s$a_.f(Unknown Source)
at com.esri.sde.sdk.client.SeCoordinateReference.h(Unknown Source)
at com.esri.sde.sdk.client.SeCoordinateReference.f(Unknown Source)
at com.esri.sde.sdk.client.SeLayer.c(Unknown Source)
at com.esri.sde.sdk.client.SeLayer.a(Unknown Source)
at com.esri.sde.sdk.client.SeLayer.read(Unknown Source)
at com.esri.sde.sdk.client.s$a_.a(Unknown Source)
at com.esri.sde.sdk.client.s.a(Unknown Source)
at com.esri.sde.sdk.client.b.a(Unknown Source)
at com.esri.sde.sdk.client.SeLayer.getInfo(Unknown Source)
at com.esri.sde.sdk.client.SeLayer.<init>(Unknown Source)
at com.esri.sln.ss.core.search.SdeSearchEngine.searchTheme(SdeSearchEngine.java:62)
at com.esri.sln.ss.core.map.tool.SdeIdentify.useTool(SdeIdentify.java:138)
at com.esri.sln.ss.core.servlet.ToolServlet.performPost(ToolServlet.java:170)
at com.esri.sln.ss.core.servlet.BaseServlet.doPost(BaseServlet.java:138)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:419)
at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:378)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1509)
at java.lang.Thread.run(Unknown Source)
Jun 16, 2009 11:58:33 AM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet toolservlet threw exception
java.lang.OutOfMemoryError: Java heap space
Kees Jan Koster
JavaMonitor Support
Rancher

Joined: Mar 31, 2009
Posts: 251
    
    5
Dear Eli,

Well, the memory in task manager is not likely to change much, because that is probably pre-allocated to Java at JVM start. You need to look into the running application at what happens with the heap space.

You can do that with jconsole or visualvm or (my favourite) Java-monitor. Here is what a memory leak looks like when seen through Java-monitor: http://java-monitor.com/forum/showthread.php?t=150


Java-monitor, JVM monitoring made easy <- right here on Java Ranch
Eli Wood
Ranch Hand

Joined: Sep 04, 2008
Posts: 37

Kees Jan Koster wrote:Dear Eli,

Well, the memory in task manager is not likely to change much, because that is probably pre-allocated to Java at JVM start. You need to look into the running application at what happens with the heap space.

You can do that with jconsole or visualvm or (my favourite) Java-monitor. Here is what a memory leak looks like when seen through Java-monitor: http://java-monitor.com/forum/showthread.php?t=150

Thank you for the recommendation on the monitoring software. I will try it as soon as I have a chance if the problem persists.

The memory parameters for this Tomcat instance specify an initial memory pool of 512 MB and maximum of 1024 MB. When I start Tomcat, I can watch its memory usage in Task Manager climb from about 80 MB initially to about 250 MB. If I play around with some of the other webapps, I can cause the memory usage to grow to ~1 GB, then shrink (my guess is this is when the GC is run) but if I use this particular webapp it will immediately throw the Java heap space error although the memory usage in Task Manager is comparatively low at that time (~300 MB).

I hope the memory profiler helps, and I will post back after I get the chance to use it, but I cannot understand how I am getting the Java heap space error when 1. The server has more memory available and 2. Task Manager shows low memory usage compared to other times.

Thanks again for the monitoring recommendations. I need something that will allow me to monitor a specific webapp, hopefully I'll find one of these tools will allow that once I have the chance to look into that.
Kees Jan Koster
JavaMonitor Support
Rancher

Joined: Mar 31, 2009
Posts: 251
    
    5
Dear Eli,

It may be that Java is trying to allocate a massive chunk all at once and decides that is impossible without ever actually allocating it.

Have you checked the code at the points where the apps throws exeptions? What does it allocate there? Something big?

Also, you gave the JVM 1G, so it will not use (much) more than that. Java uses what you give it. It does not scan the local machine and take what is there.
Eli Wood
Ranch Hand

Joined: Sep 04, 2008
Posts: 37

Kees Jan Koster wrote:Dear Eli,

It may be that Java is trying to allocate a massive chunk all at once and decides that is impossible without ever actually allocating it.

Have you checked the code at the points where the apps throws exeptions? What does it allocate there? Something big?

Also, you gave the JVM 1G, so it will not use (much) more than that. Java uses what you give it. It does not scan the local machine and take what is there.

Kees,

I did not mean to give the impression I thought Java was scanning the local machine.

Functionally, at this point the code is just executing a query and bringing back some records from a database. It's a little more complicated than that as it's going through some GIS middleware but there's no reason it should be trying to allocate large amounts of memory at this point. I will have to wait until I can look closer to talk more specifically about exactly what is happening. But it worked pretty well a couple of months ago and there's no way it was allocating that much memory.
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12806
    
    5
Possible sudden memory requirements include recursion and infinite loops without a stopping point.

Bill
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: java.lang.OutOfMemoryError: Java heap space