NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Dave, I think I have fixed this problem. I could make this happen by creating a heavy load on both of my processers (running 2 separate scripts that looped forever) and then running the IDV. What's happening is that JFileChoosers are being created in 2 separate threads (the chooser and the JythonManager). This is locking something up deep down in the JDK. See here for a number of bug reports about this: http://www.google.com/search?hl=en&q=sun.misc.Unsafe.park+jfilechooser&btnG=Search&aq=f&oq= I modified visad.util.TextEditor (created by the JythonManager) to not create a JFileChooser right away. I also modified our FileChooser to set a property to false: public void updateUI() { putClientProperty("FileChooser.useShellFolder", Boolean.FALSE); super.updateUI(); } This also has the effect of speeding up the creation of the filechooser. I also start up the IDV monitor earlier in the initialization process. You can get a stack trace from it by hitting: http://localhost:8788/stack.html -Jeff Ticket Details =================== Ticket ID: MHT-202012 Department: Support IDV Priority: Normal Status: Open