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
