Re: running VisAD in an applet

If you override stop() and start(), can you control the behaivor better?
I've had to do this in animation applets to prevent eating all the
cycles when the browser goes to a different page, but also to keep a
separate thread running to keep track of the time (for auto-reloads) --
until the browser calls destroy() to kill off everything...anyway,
thought it was worth mentioning.

tom


"Alexander, Ben" wrote:
> 
> After struggling with this problem for a week, I think I know why I'm having
> trouble.  I don't, however, know how to fix it, so I want to troll this list
> one more time.  First, the problem statement:
> 
> I can run VisAD as an applet, and it works beautifully the first time I hit
> the page.  If I go to another page and then return to the page with the
> VisAD applet, then my applet appears to hang, no matter how simple I make
> it.
> 
> Here's my theory about what's going wrong:
> 
> Under IE 5.0, using the Java plug-in 1.3, the JVM loads my applet and
> visad.jar the first time they're needed.  The next time around, the browser
> calls Class.newInstance() (which performs a shallow copy) to generate a new
> version of my applet class, while keeping the instantiations of any classes
> that were loaded from the visad.jar.  I know that VisAD is still loaded,
> since I can call ScalarMap.getScalarName("myscalar"), for example.  The
> instance variables in my applet are all new, though my static variables are
> still the same.  Now the trouble starts.  That first instance of my class is
> gone for good, so the garbage collector can start picking it to pieces, and
> since there are no explicit references to the information stored in VisAD's
> namespace, I think that the memory VisAD has allocated starts to be picked
> apart as well. The classloader doesn't bother to reload visad.jar from
> scratch, since it knows that it loaded visad.jar once already, and assumes
> that I've kept explicit pointers to any memory I want saved.  So now I'm in
> deep trouble, as I stand on instances of VisAD classes that are dissolving
> beneath me.
> 
> Note:  I think this IS NOT a VisAD bug (I'd call it instead a browser and/or
> Java plug-in bug).  There may, however,  be aspects of VisAD that would
> allow me to get around the problem.  If, for example, I could get a pointer
> to the root of the data structure that VisAD uses internally, then I could
> set a static variable within my program to point to it, and everything would
> be protected from the GC, and I could use the variables I created the first
> time through.  Or, if there were a way for me to tell VisAD to start fresh
> and give me all new variables, then, while loading would be slower, at least
> everything would run reliably.  Alternatively, if there were a way to tell
> VisAD to unload everything it has allocated, then that would do it too.
> Maybe subclassing the classLoader to make it load new versions instead of
> referencing old versions would work, but I'm not certain.  Don't bother
> suggesting that I simply make every VisAD variable that I use static, since
> I've tried and that approach doesn't work (perhaps implying that my solution
> #1 would fail too?).  I imagine that there are other approaches, but since I
> don't know how VisAD stores its internal variables I don't have any other
> ideas right now.
> 
> I would really like to use VisAD in our front end, and I feel as if I'm 95%
> of the way there, with only this last big problem standing in my way.  Is
> there anybody who can shed some light on my troubles?  Please contact me
> offline if you're interested and want to see my source, or if I could
> perform any work which might then be folded back into somebody else's
> project (as well as my own).
> 
> Ben
> balexander@xxxxxxxxxx
> 781-994-0428

-- 
Tom Whittaker (tomw@xxxxxxxxxxxxx)
University of Wisconsin-Madison
Space Science and Engineering Center
Phone/VoiceMail: 608/262-2759
Fax: 608/262-5974