Thanks for the info.
> . . .
> There are two problems we've encountered:
> 1) making sure the display is completed before making
> the JPEG. Using the sync for getImage helps with this,
> but it not fail-safe.
I'll try to look into this.
> And the biggest obstacle:
> 2) The excessive time it takes to invoke the JVM, just
> to create a display. If you look at the way that most
> Unidata sites use GEMPAK and McIDAS to do something
> similar to what you say Vis5D users do, then the number
> of JVMs running at any time on a system would be a
> great load. Consider generating a GIF for every NEXRAD
> Level III base reflectivity image that comes in (~20/minute)
> on a data feed and it takes 5 seconds just to start the JVM.
> You would rapidly get behind. You might be able to get away
> with having an IDV running in the background, and then using
> that to generate products in, but then you'd have to worry about
> threading issues (e.g., concurrent actions to the IDV).
When we connected Vis5D to ECMWF's Metview system in 1998,
we used an approach that might help. We added a command
line option to Vis5D to specify the name of a pipe file.
If this option was used, Vis5D listened at the pipe file
and any character lines that came across were interpreted
as the names of TCL script files, which were read and
executed. This enables Metview to invoke complex Vis5D
operations by constructing and sending TCL scripts.
Perhaps, given an appropriate command line option, the IDV
could register an object with the rmiregistry. Then events
could start small Java programs that would connect with the
RMI object and send it scripts for the IDV to execute.
This would be a nice way to re-use an IDV, if all the memory
leaks in the IDV, VisAD and Java3D can be plugged. If the
IDV always re-used one DisplayImpl, that would help.