IDependOn-Set: 1
IDependOn-Set: 116
IDependOn-Set: 130
IDependOn-Set: 2
IDependOn-Set: 7
IDependOn-Set: 98
LastModifiedSecs: 938716014
Parent: 7
SequenceNumber: 15
Title: How do I set the memory size of my JVM in automatic mode? (Out of memory exceptions)
Part: 0
Author-Set: cmcclanahan@mytownnet.com
LastModifiedSecs: 924622740
Type: 
Lines: 5
In your "jserv.properties" file, add a setting like this:

wrapper.bin.parameters=-mx64m

to set the maximum heap size to 64 megabytes.
EndPart: 0
Part: 1
Author-Set: jon@working-dogs.com
HideAttributions: 1
LastModifiedSecs: 926034600
Type: 
Lines: 78
From: Godmar Back <gback@cs.utah.edu>
To: java-apache-users@list.working-dogs.com
Subject: Re: Exceptions / Errors and catching unexpected ones.
Date: Thu, May 6, 1999, 4:44 PM

OutOfMemory exceptions are thrown when the JVM runs out of heap space,
not stack space.  By that time, the JVM will have tried to garbage
collect and drop weak refs already.  (Which, btw, the suggestion to 
invoke System.gc() in a catch(OutOfMemory ) clause does not work.)

Let me quote the VMSpec:

    3.5.3
        [...]

        If a computation requires more heap than can be made available by the 
        automatic storage management system, the Java virtual machine throws 
        an OutOfMemoryError

The only instance when lack of stack of space causes an out of memory error
is when the native method stack cannot be extended.
For your convenience, I quote the complete VMSpec subsection:

    3.5.6 Native Method Stacks

    An implementation of the Java virtual machine may use conventional 
    stacks, colloquially called "C stacks," to support native methods, 
    methods written in a language other than the Java programming language. 
    Native method stacks may also be used by the implementation of an 
    interpreter for the Java virtual machine's instruction set in a language 
    such as C. Java virtual machine implementations that cannot load native 
    methods and that do not themselves rely on conventional stacks need not 
    supply native method stacks. If supplied, native method stacks are 
    typically allocated per thread when each thread is created. 

    The Java virtual machine specification permits native method stacks 
    either to be of a fixed size or to dynamically expand and contract as 
    required by the computation. If the native method stacks are of a
    fixed size, the size of each native method stack may be chosen 
    independently when that stack is created. In any case, a Java virtual 
    machine implementation may provide the programmer or the user control 
    over the initial size of the native method stacks. In the case of 
    varying-size native method stacks, it may also make available control 
    over the maximum and minimum method stack sizes.7

    The following exceptional conditions are associated with native method 
    stacks:

        If the computation in a thread requires a larger native method 
        stack than is permitted, the Java virtual machine throws a 
        StackOverflowError. 

        If native method stacks can be dynamically expanded and native method 
        stack expansion is attempted but insufficient memory can be made 
        available, or if insufficient memory can be made available to create 
        the initial native method stack for a new thread, the Java virtual 
        machine throws an OutOfMemoryError. 

How do you know that what causes the out of memory error in the case
discussed was a failure to allocate more memory for the stack?
I would have thought that this would only happen if you set a *very* large
stack limit and then entered a buggy recursive function.

You may also want to try a VM that does not dynamically expand its stacks,
such as Kaffe.  If you still get an OutOfMemoryError (as opposed to a
StackOverflow) exception, you could be sure that not being able to expand
the stack has nothing to do with it the problem --- otherwise, you would
have gotten a StackOverflowError.

In general, reacting to OutOfMemoryErrors is hard.  First, you need a
VM that supports it (Kaffe currently doesn't, I don't think the JDK does
either.) The JVM has to throw the error at a point in time where there are
sufficient resources for the program to proceed to a point where it can
drop references (either by terminating threads or by explicitly dropping
(zeroing out) references) and then invoke a gc.  This is not trivial to
implement.

        - Godmar
EndPart: 1
Part: 2
Author-Set: Tom.Howland@us.pwcglobal.com
HideAttributions: 1
LastModifiedSecs: 938716014
Type: html
Lines: 69
There are several things that one can do about out-of-memory errors. The best thing is to figure out why you are getting them. Jprobe might be useful in this regard. Unfortunately, that is not feasible for me. jserv will run for a month or two unattended before abruptly dying on an out-of-memory error.

<br><br>

I wrote a script that watches my jserv log and restarts the thing
if it starts getting servlet errors. This is brutal but effective
as far as I can tell. Here is my very nutty script:

<blockquote><small><code><pre>

#!/usr/local/bin/perl -w

# this is a lovely hack for recovering from Out Of Memory Errors in jserv

$log='/opt/apache/logs/jserv.log';
$ap='/opt/apache/bin/apachectl';

open(LOG, $log) || die "couldn't open $log: $!\n";

# jump to the end of the log

seek(LOG, 0, 2);
$| = 1;

# recover from log roll-overs by keeping track of the size of the log

$s = -s $log;

while(1){
  while(&lt;LOG&gt;){
    if(/\(ERROR\) ajp11\: Servlet Error\: /){
      next if $' =~ /ClassNotFoundException\:/;
      system("$ap stop") || die $!;
      sleep 1;
      system("$ap start") || die $!;
      sleep 1;
      system("$ap stop") || die $!;
      sleep 1;
      seek(LOG, 0, 2);
      system("$ap start") || die $!;
      my @lt = localtime(time);
      printf("%d/%.2d/%.2d %.2d:%.2d:%.2d $'\n", $lt[5] + 1900, $lt[4] + 1, $lt[3], $lt[2], $lt[1], $lt[0]);
    }
  }
  seek(LOG, 0, 1);
  sleep 1;
  my $s1 = -s $log;
  if(defined($s1)){
    if($s1 &lt; $s){
      close(LOG);
      open(LOG, $log);
    }
    $s = $s1;
  }
}

</pre></code></small></blockquote>

The other solution that has been <a href="http://www.mail-archive.com/java-apache-users@list.working-dogs.com/msg04691.html">bandied about in the mailing list</a> is to modify memory usage of the jvm. I guess that means modifying jserv.properties so that 

<code>
wrapper.bin.parameters=-Xms128m -Xmx156m
</code>

for Java 2.

<br><br>

<address><a href="mailto:Tom.Howland@us.pwcglobal.com">Tom Howland</a></address>
EndPart: 2
