Re: [Wrapper-user] Garbage collection and timeouts

[<da...@ix...>]

In article <3F1...@ta...>,
Leif Mortenson  <wra...@li...> wrote:
>Mike,
>Ouch. You are right about avoiding calling System.gc() Still that is one
>long lock. You are using quite a bit of memory though.

Turns out we aren't calling gc() directly.

One thing I'd noticed was that we were thrashing objects left and right.
Something along the lines of:

while (true) {
  try {
   Object o[];
   o[0] = this;
   do stuff with o...
   }
   maybe break;
}

And the "do stuff with o" wasn't blocking like it was supposed to.  Whoops.

Still, yeah, we do have one processing mode where we allocate several
megs of a bunch of small objects that all go out of scope at once.  Still
working on that one.

>What is the timeout that you are extending? Setting the
>wrapper.ping.timeout=300

I've upped it pretty high for the time being so we can run our other tests
without rebooting in the middle of it.  :->  Correctness first, then speed.

>In general though I have found that newer JVMs do a very good job of
>handling GC
>on their own. Forcing a GC just serves to slow things down. It is
>usually better to
>let the JVM decide when it is best to do a GC. The GC that the JVM does is
>generally must more light weight. It is still taking over a second on
>your app
>though.

One of the problems is that we're running the RMI Server in process, so
that automatically kicks in System.gc() once a minute, regardless.  And
we're not to the point of tweaking the properties that will control that
rate.  Soon, though I think.

We're running 1.4.1_01 right now, but holding off switching to 1.4.2 until
next week.  Still, we do have 3 other GC mechanisms we can look at that
might help our situation.

Thanks!
mrc

-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc