hi all experts out there,

  I am currently using tomcat 5 and j2sdk1.4.2 to run my jsp(s). the problem is that this particular jsp run fine for the first few run. but after that i will hit this error, java.lang.OutOfMemoryError.
  After i stop start my tomcat, it runs perfectly fine again for the first few run before hitting the same error again. is there a sollution to this problem...

  Thanks in advance.
Who is Participating?
sudhakar_koundinyaConnect With a Mentor Commented:
There are several ways to collect the objects into garbage

1. Once the data is executed. If you think that is no long is necessary then nullify  the object,

 for example if Hashtable object contains some data and if you think it is no long required, then immediately nullify it.

2. call System.gc()

3. if you are working with sessions, check if you are handling the session objects correctly or not

for example

4. Don't put huge data into memory. That will always raise the problem. You need to design correctly, if such situation araises
What are you doing in this JSP...?   Are you storing a large amount of information in the Session, the ApplicationContext or in some static area such as a singleton...?    

If so, this could cause an OutOfMemoryError if you are repeatedly invoking the same page (and accumulating data each time).  

When the Garbage Collector runs, it tests to see if there are references to candidate objects that are reachable from currently active threads before cleaning them up.  
It sounds like you have some sort of memory leak.  You are not freeing some sort of resource or like lhankins says, you are storing something on the ApplicationContext or the UserSession.  We need more information in order to proceed.
Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

Problems may be because of following reasons.

In Your JSP/Servlets/Java Beans/Javac Classes

1. if u are placing huge data in  sessions, there is possibility of breaking of server
2. if u have any static variables that holds the huge data and if they aren't nullified in your classes/servlets.

The mistake may be if  you  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.
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.
Its also possible that you are doing a lot of procesisng and just don't have enough memory allocated to the JVM.  You can increase this by specifying the Xmx option to Java when you start Tomcat.
Now one more question is

Are ur JSPs using any threads to execute some codes??

If so you need to take care of them

Following link might gives you an idea to resolve ur problem, if you are dealing with threads in JSP/Servlets/Beans
OutOfMemoryError can also happen in a situation where you accidently cause an infinite recursive loop. Check for those too.

This can easily happen when you for example execute a call in a listener method that indirectly causes a new event to be passed to the same listener method and thus starts an infinite loop until OutOfMemoryError is thrown. This doesn't need to happen in a listener code, but as Java often uses observer pattern it is common -or atleast possible, hopefully not common ;-) - in these situations.
If not of the above, It could be a system error.
Try to check your RAM and see if there is some damage.

sunmasterAuthor Commented:

  u mention about garbage collection, how do i force a garbage collection...? I am still new at this JSP/Servlet thing. FYI, this JSP will call a servlet and return back to this same JSP.

Thanks in advance.
Continuing sudhakar_koundinya's list (ways to collect the objects):
5. When you are done with session objects remove them
6. When you are done with application context objects remove them
7.  Allow the user to "logout" of your application.  On the logout, remove the users' seession by calling session.invalidate();
This is Just for Your Information

The fundamental strategy about garbage collection:

    At some frequency, distinguish live from dead objects (tracing).  Reclaim dead ones.

Live objects are those that still have something referring to them.  You find them by starting at the roots and walking all pointers until you run out of objects to look at.  Any objects that you did not visit are dead objects.   Roots are things like statics (globals), locals, and registers of active methods.   The following metaphor usually helps:

    You go into the refrigerator and pull out a bowl of grapes.  You pick up the grapes by the stem and look at the bunch of grapes.  You can reach every grape from the root/stem, right?  These are analogous to the live objects in the heap of your running program.  Now, look at the bowl and in the bottom you'll seem some really gross looking black and blue grapes.  These are not reachable from the stem and are analogous to dead objects in your heap.

What is a conservative collector?  A conservative collector is one that cannot always distinguish between integers and pointers.  It must assume that if something smells like a pointer, it is (good for C and friends where it's hard to tell anyway).  This can cause "memory leaks" because an integer can just happen to have the value coincidental with the address of a valid object, meaning that object might not be collected ever.

What's a reference counting collector?  This kind of collector is the most naive, but easiest to understand.  You simply add code to increment a count every time you make a new reference to an object and decrement the count every time you lose a reference to that object.  When the count goes to zero, you free that object.   Unfortunately, it is pretty slow and can't handle reference cycles where object A points to object B and vice versa.

The original Java VM had a mark and sweep collector, which at some frequency, walks every live object in the system, marking them.  After this pass, all remaining objects are considered dead and "swept" away.  This is better than reference counting, but can cause disruptive pauses while the computer walks the objects in the heap.  Also, it badly fragments memory, which screws up virtual memory locality characteristics and so on.

A nice twist on this is to build a copying collector.  A copying collector does the same thing as the mark and sweep except that it copies all live objects to form a solid block of live memory, leaving the rest of the heap as dead space.   This is faster because you don't have to walk the dead objects and makes memory allocation as simple as bumping a heap pointer (well, almost <wink>).  The cost is that you have to update every pointer in the system to refer to the objects in their new locations.  Of course, with the finalize() method in Java, you may have to walk the dead objects anyway to execute this method before the objects die.

The next improvement is the generational scheme.  This scheme operates under the observation that most objects live only a short time, but the rest tend to live much longer.  So, you can split heap into generations: a  nursery and mature spaces.  This leaves only a few live objects in the nursery to walk during garbage collection making each collection phase faster and, thus, less disruptive to the running program.  Of course, this doesn't avoid the need for collection of the big mature space once in a while.

There is a lot more involved than meets the eye, but garbage collection is pretty interesting--you should learn more about it if you can.  This note is but the tip of the iceberg as they say.
8. When you are working with struts and JSP forwards once done with your request attributes
May be this is out of topic but i find these tips should be konwn to your jsp programmers
>>your jsp programmer
Type- o Error

every jsp programmer
Murali MurugesanFull stack Java developerCommented:
Try using -Xmx512m --> the full size of ur RAM,
while starting the server..

thanks :)
So how did u solve ur problem??

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.