Application Server Solutions for Microsoft IIS and ASP.NET
       solutions   products   partners   company   support   downloads         store
ServletExec Self-Help: FAQ
Back to Search >  Back to Search Results

Faq ID 127
Product ServletExec
Category Debugging, Known Limitations and Workarounds
Question I am getting java.lang.OutOfMemoryError when running my code inside ServletExec. What are the possible causes of this and how can I fix it?
Answer There are many possible causes for this problem. You will have to do some investigating in order to learn the cause in your case. Here is a list of some possible causes:
  1. One possible cause is that your code is actually hitting the limit of available RAM that is available to the JVM. Here are some examples of cases in which this can potentially occur:
    • you are accumulating data in the Application, or Session scopes across many requests and not cleaning up the data soon enough
    • you are reading in (or generating) a large file (or a large amount of response data)
    • you are receiving a very large ResultSet from a database query
    • your servlet/jsp code acts as a client to some external server/application (the ArcIMS Connector Servlet acting as a client to the ArcIMS Spatial Server would be one example of this) and the client code is receiving a very large response body from the external server. Another example would be if your Servlet/JSP code were acting as a Web Service client and was receiving a large XML response from a Web Service... so large that it exhausts all available RAM.

    ServletExec (and your Java servlet/JSP code) runs inside the Java Virtual Machine. It is the Java Virtual Machine which allocates a finite amount of RAM for itself in which to run (called the Heap Size). Different versions of JVMs have different default Max Heap size settings. However it is entirely possible to configure this by passing the appropriate options to the java interpreter upon startup. SE FAQ #318 explains how one would pass options to the java interpreter in the various configurations of ServletExec.

    As for which options to pass:
    Study what is said about -Xmsn (min heap size) and -Xmxn (max heap size) under the "Non-standard options" heading at:
    After increasing the Max Heap size, you need to reinitialize the JVM that is being used.

  2. Another possible cause may have to do with the fact that JSP pages create a Session Object by default. If your site has many JSPs, that do not need to use the session object, then consider using a page directive to disable the creation of the Session Object on those pages. You may also want to consider shortening the lifespan of your sessions, either via the SE admin UI, or programmatically in your code session.setMaxInactiveInterval. You should also consider having your users logout, allowing your code to call session.invalidate() right then so that the session won't hang around until it's expired. Also, if you were to use a stress testing tool that did not maintain the session id cookie on subsequent requests then a session object would be created on every request which would most certainly exhaust the available heap size very quickly.
    Creating a brand new session on every single stress test request is not realistic.
  3. Another possible cause is that your Java code is somehow using a resource in such a way that the resource is not being properly released (basically a memory leak). This resource may be obtained via: Your own code, Native calls, or using 3rd party software. Solving this problem can be more difficult, especially if it is due to code that you did not write. Isolating the problem to its simplest, consistently reproducible case is very important. This means you would need to:
    • Instrument your code, comment out sections while retesting to locate the failure point
    • Look for patterns (does the problem occur only on certain requests?), etc...
    • Look in your webserver's access log to see what was being requested at the time of the failure
    • SE 4.x and higher have some built-in monitoring abilities (Threads, Requests, Sessions) that may provide clues.
    • Consider using a profiling tool.
      Information about profiling tools (such as OptimizeIt) can be found in SE FAQ #57. If you do use OptimizeIt, you need to know the following:
      OptimizeIt has 1 wrinkle that we know of. It's a sort of memory leak which is discussed on the SE Interest List. There may in fact be configurations that can be made to OptimizeIt, to alleviate that issue. But that's a question for the makers of OptimizeIt.
    • Check your application's usage of sessions and other persistent scopes. Does you application store lots and lots of data into the session scope (or the application scope)? If so is that data cleaned out as soon as it could be [via session.invalidate() or by setting the session lifespan to a lower value]

company media information terms of use privacy policy contact us