Update Errors and Data Management

[Wilfred L. Guerin]

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]

[Harry Parker]

Hello Wilfred,

Is your message in response to a previous post? If so, I'm not sure what it is.

You mention serious errors, but without any specifics. That makes it very difficult to pinpoint the source of the errors, which is of course the first step in finding a solution.

Which
    "binary .exe"?
    ".jar"?
    OS and version?
    Java and version?
"Installing the newest version" of which?

These all make a difference. New ImageJ versions have fixed known memory management problems in older versions.


What does the error message say when JAR files to load or the software crashes?  Can you open the JPG files with another program successfully? (Perhaps the files are corrupt.) Better save those raw files until you are confident that the JPGs are good.
 

Crashing problems may not be a software problem at all, but a hardware problem such as a corrupted disk or system memory, or network problems.  Do the errors go away when you restart ImageJ or reboot your machine? (Perhaps a memory leak has filled available memory.)  Can you reproduce the problem on a 2nd machine?

I've had similar problems as you describe in the past with certain ImageJ plugins.  Some do not check for all possible errors (i.e., exceptions) when calling methods, leading to crashes rather than helpful error messages.  However, adding checks for possible exceptions (especially common file system or network or memory allocation exceptions)  helps users know when a system limit has been reached.


Adding a database will not solve any of these problems. Better error checking in ImageJ plugins would help point to the source.

I have a 100 Mb Ethernet connection to our large and fast file servers, but I've learned its much faster to transfer all images to the local machine before opening and saving for the 9 MB images I'm typically dealing with.  A RAM disk might be faster. A network is much slower.

Hope these suggestions help.


--  
Harry Parker  
Senior Systems Engineer  
Digital Imaging Systems, Inc.

----- Original Message ----
From: Wilfred L. Guerin <[hidden email]>
To: [hidden email]
Sent: Saturday, August 11, 2007 9:16:42 PM
Subject: Update Errors and Data Management

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]





       
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell.
http://searchmarketing.yahoo.com/