Re: Resource Leak

Hi Bill et al,

Adding display.disableAction() does not help in the MemoryTest example.
However, if the map is to RGB instead of XAxis, disableAction() stops
the leak.

Is there a good reason why disableAction() stops a RGB map setRange but
not a XAxis map setRange? I'd like to be able stop this leak with
disableAction on my non-visible displays. 

Thanks,
Doug

Bill Hibbard wrote:
> 
> Doug,
> 
> I'm sure this Java3D bug report that Tom found is the cause
> of your problem. There is no good way for VisAD to compensate
> for this. However, your application can keep track of when
> its DisplayImplJ3Ds are not visible in a Frame, and refrain
> from calling ScalarMap.setRange() and other operations at
> that time. You may be able to avoid most operartions simply
> by calling DisplayImplJ3D.disableAction() when the display
> is not visible.
> 
> Good luck,
> Bill
> 
> Tom Whittaker wrote:
> >
> > I agree with Tom...I ran this on Windoz and the result was the same --
> > it just took longer to gobble up the memory...
> >
> > Given Don's observation that if the window is displayed, the leak
> > doesn't, well, leak, I cannot help wonder if this bug isn't related:
> >
> > http://developer.java.sun.com/developer/bugParade/bugs/4727054.html
> >
> > It says, in part:
> >
> > "Current architecture allocate message and send to MasterControl
> > every time an attributes of scene graph changed.
> > This is most like done by behavior thread.
> >
> > Under normal circumstance when window minizimize all Java3D threads
> > are put to sleep so there is no message passing in the system
> > from Behavior or other Java3D thread.
> >
> > However if there is a free running thread which continously change
> > scene graph attributes the message will continously accumulate in
> > the system and MasterControl thread will not wake up to process
> > any message. This result in out of memory after a while.
> >
> > It is not recommend to do so even though window is not minimize
> > since the thread may pump message to
> > java3d system too fast that java3d can't handle. Thus can dramatically
> > slow down the system. Besides, java3d can only change scene graph
> > as fast as the frame rate. So if the transform is changed 10 times
> > between each frame the first 9 time are ignored. The best way to
> > do so is to use behavior thread which gaurantee synchronized with
> > the Java3d system and frame rate.
> >
> > This bug will most likely mark "will not fix" later."
> >
> > tom
> > --
> > Tom Whittaker (tomw@xxxxxxxxxxxxx)
> > University of Wisconsin-Madison
> > Space Science and Engineering Center
> > Cooperative Institute for Meteorological Satellite Studies
> > Phone/VoiceMail: 608.262.2759
> 
> --
> ----------------------------------------------------------
> Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI  53706
> hibbard@xxxxxxxxxxxxxxxxx  608-263-4427  fax: 608-263-6738
> http://www.ssec.wisc.edu/~billh/vis.html

-- 
*----------------------------------------------------------------------*
| Doug Lindholm, Software Engineer          |  E-mail: lind@xxxxxxxx   |
| Research Applications Program             |   Phone: 303-497-8374    |
| National Center for Atmospheric Research  |                          |
| P.O. Box 3000                             |     There's no place     |
| Boulder, Colorado 80307-3000              |        like $HOME        |
*----------------------------------------------------------------------*