Posted by
Wilfred L. Guerin on
Aug 12, 2007; 2:16am
URL: http://imagej.273.s1.nabble.com/Update-Errors-and-Data-Management-tp3698644.html
Two main topics:
first, the old binary .exe has failed to load the .jar, especially when
updated, and appears to not be fixed with installing the newest version.
Whatever jre loader this is should be cleaned up, but I note the need to not
mess with local files, especially in audited environments.
Secondly, the memory handling is a persistent problem with java, we all know
this, but if there is to be a continued use of a binary loader to handle the
JRE, it is logical to package it with some sort of comprehensive and fast
database system that can also be used as the primary memory manager. The new
sun DB has some qualities that are usable, however it would need to be
fairly inlined to make memory containment accessable for high speed
processing.
This time around, using a signed imagej via applet loader, we intend to max
out the processing capability in a diverse distributed system, however I
would prefer to make use of IJ as the host again given the suitability for
scientific environments, and the various effective interfaces.
On multiple ocasions today IJ crashed with memory exception when trying to
load SMALL JPG images from remote server, the .exe does not find the jar,
and the original compressed (raw) file is not held by default...
There are many methods of runtime access of image compression formats, so I
wonder why this type of failsafe is not included by default. Also the
ability to use any available memory containment (remote server, local db
remote to java) for buffering and backup, regardless if the java client
(processor) crashes or disappears, using a conventional database remotely
for data management is very viable with current average wire speeds. Also
significantly more effective for large shared (buffered) data sets.
Please let me know what options have been researched, and suggestions on
this topic,
-Wilfred
[hidden email]