URGENT !!! - java.lang.OutOfMemoryError


Web tier: servlets, JSP, Web frameworks: URGENT !!! - java.lang.OutOfMemoryError

  1. URGENT !!! - java.lang.OutOfMemoryError (3 messages)

    Hi !
    I have session bean acting as client for entity bean with JSP as client. I successsfully deployed the bean in Windows NT 4.0, and my app server is weblogic 5.1 . WHen I run the jsp client from the browser, sometime Iam getting the "java.lang.OutOfMemoryError", the following is the error message :

    Servlet failed with Exception
    at java.lang.StringBuffer.setLength(StringBuffer.java, Compiled Code)
    at weblogic.servlet.jsp.JspLexer.htmlSection(JspLexer.java, Compiled Code)
    at weblogic.servlet.jsp.JspLexer.javaSection(JspLexer.java, Compiled Code)
    at weblogic.servlet.jsp.JspLexer.javaSection(JspLexer.java, Compiled Code)
    at weblogic.servlet.jsp.JspLexer.mEXPRESSION(JspLexer.java, Compiled Code)
    at weblogic.servlet.jsp.JspLexer.mSTANDARD_THING(JspLexer.java, Compiled Code)
    at weblogic.servlet.jsp.JspLexer.mTOKEN(JspLexer.java, Compiled Code)
    at weblogic.servlet.jsp.JspLexer.nextToken(JspLexer.java, Compiled Code)
    at weblogic.servlet.jsp.JspLexer.parse(JspLexer.java, Compiled Code)
    at weblogic.servlet.jsp.JspParser.doit(JspParser.java, Compiled Code)
    at weblogic.servlet.jsp.JspParser.parse(JspParser.java:109)
    at weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:97)
    at weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java, Compiled Code)

    What could be the problem. Solution is needed urgently.

  2. I once had faced the same problem. The mistake I did was a cyclic include. That is when u try to resolve a include command you end up in pointing to the same jsp.

    for example jsp1 includes jsp2 and jsp2 includes jsp1.

    Check your code.

  3. There are three possible causes for an OutOfMemoryError. The first is that the JVM has a real memory leak, caused by a bug in the internal implementation of the JVM heap management. This is extremely unlikely. All JVMs are tested very strenuously for this, and it would be the absolute top priority bug if anyone found such a bug. So you can pretty much eliminate this possibility.

    The second possible cause of an OutOfMemoryError is that you simply haven't got enough memory available for the workings of your application. There are two possible solutions to this situation, either increase the available JVM heap size, or decrease the amount of memory your application needs. Increasing the available JVM heap size is simply done with the -Xmx parameter to the JVM. If you still have the memory problem because you have already increased this parameter as much as possible (up to available RAM, don't exceed real system memory or your application will page and crawl to a halt), then you need to reduce the amount of memory being used by your application. Reducing application memory may be simple, you may just be allowing some collections to be too big, for example using many large buffers. Or it can be complex, requiring you to reimplement some classes, or even redesign the application.

    Reader James Stauffer has pointed out that with some JVMs (e.g. the Sun JVMs), there is also a "Perm" space which holds JVM structures and class objects. If you are using a very large number of classes, it is possible to run out of space in "Perm" space, and you may need to increase the size of that space, e.g. with the Sun JVM using the -XX:PermSize and -XX:MaxPermSize options.

    The third possible cause of an OutOfMemoryError is the most common, unintentional object retention. You are hanging on to objects without realizing it and this is causing your heap to grow and grow until you have nothing spare.

    Dealing with an OutOfMemoryError:

    Is it an internal JVM bug? Extremely unlikely. Highest priority JVM bug if true (so how come no one else has found it yet?)
    Not enough memory for actual application needs? Two options:
    Increase the maximum heap size with -Xmx parameter (or Perm space size with -XX:MaxPermSize); or
    Decrease the amount of memory needed by using smaller collections/caches/tables/objects/..., i.e. by tuning object sizes, by redesign, and by reimplementation
    Unintentional object retention? Find the root object holding on to the unintentionally retained objects, and change it to release those objects. A generic procedure for doing this is outlined in this IBM developerworks article. A summary of the procedure is
    Wait until the application has reached the steady state, where you would expect most new objects are temporary objects that can be garbage collected; typically this is after all the application initializations have finished.
    Force a garbage collection, and take an object snapshot of the heap.
    Do whatever work it is that is causing unintentionally retained objects.
    Force another garbage collection and then take a second object snapshot of the heap.
    Compare the two snapshots to see which objects have increased in number from the first snapshot to the next. Because you forced garbage collections before the snapshots, the objects left should all be objects referenced by the application, and comparing the two snapshots should identify exactly those newly created objects that are being retained by the application.
    Using your knowledge of the application, determine from the snapshot comparison which of the objects are being unintentionally retained.
    Track back-references to find which objects are referencing the unintentionally retained objects, until you reach the root object that is causing the problem.
  4. AJP, you said you SOMETIMES get this error. What are the circumstances? Judging from your output, Srinivas' diagnosis seems reasonable. The error appears to occur when the server is translating and compiling your jsp. If you have compile-time includes, <%@ include="..." %>, check that the references don't lead you in circles, as Srinivas suggested.