|
Replies:
16
-
Last Post:
Apr 2, 2008 10:21 AM
by: cobrien
|
Threads:
[
Previous
|
Next
]
|
|
|
|
|
|
JAI IIO service provider list - Replacement for ImageRead JPEG 12-bit
Posted:
Mar 31, 2008 4:55 AM
|
|
|
Hi all,
We need to read and visualize JPEG 12-bit grayscale images from traffic cameras for a large traffic system (Windows i386). Currently we are using JAI 1.1.3 with the Image I/O Tools 1.1. Due to problems with some images that comes corrupted from the camera (large sections of the file contains random bytes - garbage = lack of EOI) that crashes the VM (the IIO codeclib DLL crashes), we move to the "last" version of the Image I/O Tools, the "nightly builds", that fix the problem (2007-12-03 release of DLLs).
The problem is about deploying a non-stable product on a production environment. After a 3-year development using JAI and IIO, we found the problem, but the solution provided by JAI-SUN does not satisfy us/the client completely.
The Java JDK/JRE comes with regular updates (for 1.3.1, 1.4.2, 1.5.0., 1.6 versions), but others products like JAI/IIO releases a new version each several years. Questions about this in the forums gave us the same response, "no planned release yet".
So, we have to look for alternatives:
1) Convince the client that the IIO "nighltly build" is suitable for production environments.
2) Look for another IIO service provider different than SUN wich implements the "ImageRead" operation to load the JPEG 12-bit.
3) Move to another Image Processing product different than JAI with IIO
The 1) is on the way, but the client claims a lot of this alternative.
The 2) is the better for us, only replace a bundle of jars and DLLs.
The 3) requires to rewrite some portions of code and perform intesive-testing in order to guarantee a bug-free solution.
The question is about the 2) alternative, because we do not found any service provider for the "ImageRead" operation different than SUN guys with support for JPEG 12-bit grayscale images.
There are any list of servide providers (third-party plug-ins) for the JAI-IIO operations, like ImageRead? There are any other operation from a third-party plug-in equivalent to ImageRead?
Thanks in advance, David
|
|
|
|
|
|
|
Re: JAI IIO service provider list - Replacement for ImageRead JPEG 12-bit
Posted:
Mar 31, 2008 11:32 AM
in response to: nkpevfqy
|
|
|
What is the time frame or deadline by which you will need a final build which fixes the problem?
Brian
> Hi all,
>
> We need to read and visualize JPEG 12-bit grayscale
> images from traffic cameras for a large traffic
> system (Windows i386). Currently we are using JAI
> 1.1.3 with the Image I/O Tools 1.1. Due to problems
> with some images that comes corrupted from the camera
> (large sections of the file contains random bytes -
> garbage = lack of EOI) that crashes the VM (the IIO
> codeclib DLL crashes), we move to the "last" version
> of the Image I/O Tools, the "nightly builds", that
> fix the problem (2007-12-03 release of DLLs).
>
> The problem is about deploying a non-stable product
> on a production environment. After a 3-year
> development using JAI and IIO, we found the problem,
> but the solution provided by JAI-SUN does not satisfy
> us/the client completely.
>
> The Java JDK/JRE comes with regular updates (for
> 1.3.1, 1.4.2, 1.5.0., 1.6 versions), but others
> products like JAI/IIO releases a new version each
> several years. Questions about this in the forums
> gave us the same response, "no planned release yet".
>
> So, we have to look for alternatives:
>
> 1) Convince the client that the IIO "nighltly build"
> is suitable for production environments.
> 2) Look for another IIO service provider different
> than SUN wich implements the "ImageRead" operation to
> load the JPEG 12-bit.
> 3) Move to another Image Processing product different
> than JAI with IIO
>
> The 1) is on the way, but the client claims a lot of
> this alternative.
> The 2) is the better for us, only replace a bundle of
> jars and DLLs.
> The 3) requires to rewrite some portions of code and
> perform intesive-testing in order to guarantee a
> bug-free solution.
>
> The question is about the 2) alternative, because we
> do not found any service provider for the "ImageRead"
> operation different than SUN guys with support for
> JPEG 12-bit grayscale images.
>
> There are any list of servide providers (third-party
> plug-ins) for the JAI-IIO operations, like ImageRead?
> There are any other operation from a third-party
> plug-in equivalent to ImageRead?
>
> Thanks in advance, David
|
|
|
|
|
|
|
|
|
Re: JAI IIO service provider list - Replacement for ImageRead JPEG 12-bit
Posted:
Apr 1, 2008 3:33 AM
in response to: bpb
|
|
|
Hi Brian,
Thank you for the interest. The situation is as follows.
The traffic system was developed and tested in the DEV and QA environments. Was deployed in the production environment six months ago, to start the integration and performance testing. The integration testing starts with real traffic cameras (before were simulated) three months ago. After thousands of images from the real traffic cameras, one month ago some images comes from the camera corrupted, crashing the VM due to the clib dll. The last version of the dll, available in the nightly builds solves the problem since Dec-07. We use the new version and the crashes seems to be solved.
The problem start when the new version were deployed in the production environment, the client starts claiming about a non-stable product (JAI IIO) in PROD.
Currently the integration and performance testing phase is about to finish in 1-2 months and then the system will "go live", starting to operate with real traffic. So the time frame to replace the JAI IIO with a stable/final build is about 1-2 months, but as always, as soon as possible is preferable. Another alternative is the original question, another service provider (third party) for the ImageRead operation that supports JPEG 12-bit grayscale images.
Best regards, David
|
|
|
|
|
|
|
|
|
Re: JAI IIO service provider list - Replacement for ImageRead JPEG 12-bit
Posted:
Apr 1, 2008 5:31 AM
in response to: nkpevfqy
|
 |
Helpful |
|
|
Move the image processing out to a separate process. It's the only way to be sure that the overall application can ride out a JVM crash. That's what separate processes are for -- isolating memory spaces. We had to do this in a similar application, and it runs forever (well, a month since the last reboot and still running fine).
|
|
|
|
|
|
|
|
|
Re: JAI IIO service provider list - Replacement for ImageRead JPEG 12-bit
Posted:
Apr 1, 2008 6:06 AM
in response to: cobrien
|
|
|
Hi cobrien,
The problem is that the image processing is integrated into a visual (Swing) application, launched from a "Launcher" panel, so all applications runs within the same vm (to avoid wasting memory and other issues, like having only one vm making log, being monitored and debugged, ...). The application is used by operators that have to review the images and confirm some traffic data (all operations within a database transaction). The images are processed in a FIFO basis, retrieved from Oracle queues (AQ - the identifier only), so externalizing the image processing is a serious change in the design. The problem is only in the decoding of the image, so only will have to create a separate process to read the file from disk/FTP, decode and prepare it and return to the main visualization application. The performance is critical so currently all processing is made into memory, avoiding access to disk. Also the images are loaded in advance.
Your proposal is right, but the problem is the time frame we have for the change (big change!). The question is not a poor design in our application (I think), is a bug in the clib dlls that crashes the vm (lack of EOI) with a corrupted image, while almost any image processing tool/library is capable of decode a corrupted image without problems.
A faster and simple solution (maybe) is to use a different image processing product, like ImageJ, so only the processing code has to be changed, not introducing separate process and inter-process communication.
We will keep in mind your solution, but the client will always want to see the image, despite of corruption, so the image library should be capable of decoding such corrupted JPEGs.
Best regards, David
|
|
|
|
|
|
|
|
|
Re: JAI IIO service provider list - Replacement for ImageRead JPEG 12-bit
Posted:
Apr 2, 2008 10:20 AM
in response to: nkpevfqy
|
|
Helpful |
|
|
You can keep everything in your existing java code EXCEPT the image decode. You can even write the image decode as a java program, you just have to have it in a separate JVM that can be restarted. We do this, sort of. The external program reads over a tcp connection back to the
controlling program and returns its results via stdout, doing the absolute minimal amount of
work.
|
|
|
|
|
|
|
|
|
Re: [JAI-IMAGEIO] Re: JAI IIO service provider list - Replacement for ImageRead JPEG 12-bit
Posted:
Apr 1, 2008 7:06 AM
in response to: cobrien
|
|
|
I think that is terrible advice... The point of using Java is that
you are protected from crashes - as long as you use pure Java code.
I think your best best is to find a pure Java decoder, that can be
wrapped in an ImageReader impl (not hard) - or write one.
On Apr 1, 2008, at 6:31 AM, jai-imageio@javadesktop.org wrote:
> Move the image processing out to a separate process. It's the only
> way to be sure that the overall application can ride out a JVM
> crash. That's what separate processes are for -- isolating memory
> spaces. We had to do this in a similar application, and it runs
> forever (well, a month since the last reboot and still running fine).
> [Message sent by forum member 'cobrien' (cobrien)]
>
> http://forums.java.net/jive/thread.jspa?messageID=267047
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-
> imageio.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
|
|
|
|
|
|
|
|
|
Re: [JAI-IMAGEIO] Re: JAI IIO service provider list - Replacement
for ImageRead JPEG 12-bit
Posted:
Apr 1, 2008 8:40 AM
in response to: robert engels
|
|
|
Dream on...
robert engels wrote:
> I think that is terrible advice... The point of using Java is that you
> are protected from crashes - as long as you use pure Java code.
>
> I think your best best is to find a pure Java decoder, that can be
> wrapped in an ImageReader impl (not hard) - or write one.
>
>
> On Apr 1, 2008, at 6:31 AM, jai-imageio@javadesktop.org wrote:
>
>> Move the image processing out to a separate process. It's the only
>> way to be sure that the overall application can ride out a JVM crash.
>> That's what separate processes are for -- isolating memory spaces. We
>> had to do this in a similar application, and it runs forever (well, a
>> month since the last reboot and still running fine).
>> [Message sent by forum member 'cobrien' (cobrien)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=267047
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>> For additional commands, e-mail: interest-help@jai- imageio.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
|
|
|
|
|
|
|
|
|
Re: [JAI-IMAGEIO] Re: JAI IIO service provider list - Replacement for ImageRead JPEG 12-bit
Posted:
Apr 1, 2008 4:42 PM
in response to: Ken Warner
|
|
|
You can do it the way you state, but you will run into the same
scalability problems that plagued web CGI systems.
On Apr 1, 2008, at 10:40 AM, Ken Warner wrote:
> Dream on...
>
> robert engels wrote:
>> I think that is terrible advice... The point of using Java is
>> that you are protected from crashes - as long as you use pure
>> Java code.
>> I think your best best is to find a pure Java decoder, that can
>> be wrapped in an ImageReader impl (not hard) - or write one.
>> On Apr 1, 2008, at 6:31 AM, jai-imageio@javadesktop.org wrote:
>>> Move the image processing out to a separate process. It's the
>>> only way to be sure that the overall application can ride out a
>>> JVM crash. That's what separate processes are for -- isolating
>>> memory spaces. We had to do this in a similar application, and
>>> it runs forever (well, a month since the last reboot and still
>>> running fine).
>>> [Message sent by forum member 'cobrien' (cobrien)]
>>>
>>> http://forums.java.net/jive/thread.jspa?messageID=267047
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: interest-unsubscribe@jai-
>>> imageio.dev.java.net
>>> For additional commands, e-mail: interest-help@jai-
>>> imageio.dev.java.net
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>> For additional commands, e-mail: interest-help@jai-
>> imageio.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-
> imageio.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
|
|
|
|
|
|
|
|
|
Re: [JAI-IMAGEIO] Re: JAI IIO service provider list - Replacement for Image
Posted:
Apr 2, 2008 10:21 AM
in response to: robert engels
|
|
|
Pure java code is simply not up to the performance requirements of a lot
of image (and particularly video) processing requirements. In addition,
the number of pure java codecs is much smaller than the number available
in C. So if you want to do image processing fast, you need a dll/shared library.
Bugs in that dll or shared library CAN crash your jvm. That's just the way
it is right now.
|
|
|
|
|
|
|
|
|
Re: [JAI-IMAGEIO] Re: JAI IIO service provider list - Replacement
for ImageRead JPEG 12-bit
Posted:
Apr 1, 2008 8:39 AM
in response to: cobrien
|
|
|
I had a similar problem. I had an out of memory exception generated from
deep code I couldn't get to. So I wrote that action into a separate thread and
then I wrote a watcher thread to watch the action thread and report to my main
thread the state of the action thread. Then I put my main thread into a loop
that would exit with a succeed or fail flag. So when the action thread failed
the watcher thread kept running and reported the failure of the action thread.
Then the main thread just walked away from the whole mess unscathed after taking
appropriate steps to clean up what it could.
Works great. Now if I have a memory failure reading an image in my applet, I
can recover well enough to report that failure to the user and give information
on how to avoid that kind of failure in the future by raising the memory limits
of the JVM.
jai-imageio@javadesktop.org wrote:
> Move the image processing out to a separate process. It's the only way to be sure that the overall application can ride out a JVM crash. That's what separate processes are for -- isolating memory spaces. We had to do this in a similar application, and it runs forever (well, a month since the last reboot and still running fine).
> [Message sent by forum member 'cobrien' (cobrien)]
>
> http://forums.java.net/jive/thread.jspa?messageID=267047
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
|
|
|
|
|
|
|
|
|
Re: [JAI-IMAGEIO] Re: JAI IIO service provider list - Replacement for ImageRead JPEG 12-bit
Posted:
Apr 1, 2008 9:46 AM
in response to: Ken Warner
|
|
|
This won't really solve the problem - unless the action thread spawns
a new process (JVM).
Even though the action thread might be the one "causing" the OOM, the
thread that runs out of memory may be the watcher thread - killing
the watcher thread.
This is detailed in the Java specification.
There is a JSR underway to allow finer control of per thread memory
use, and trapping of OOMs.
On Apr 1, 2008, at 10:39 AM, Ken Warner wrote:
> I had a similar problem. I had an out of memory exception
> generated from
> deep code I couldn't get to. So I wrote that action into a separate
> thread and
> then I wrote a watcher thread to watch the action thread and report
> to my main
> thread the state of the action thread. Then I put my main thread
> into a loop
> that would exit with a succeed or fail flag. So when the action
> thread failed
> the watcher thread kept running and reported the failure of the
> action thread.
>
> Then the main thread just walked away from the whole mess unscathed
> after taking
> appropriate steps to clean up what it could.
>
> Works great. Now if I have a memory failure reading an image in my
> applet, I
> can recover well enough to report that failure to the user and give
> information
> on how to avoid that kind of failure in the future by raising the
> memory limits
> of the JVM.
>
> jai-imageio@javadesktop.org wrote:
>> Move the image processing out to a separate process. It's the
>> only way to be sure that the overall application can ride out a
>> JVM crash. That's what separate processes are for -- isolating
>> memory spaces. We had to do this in a similar application, and it
>> runs forever (well, a month since the last reboot and still
>> running fine).
>> [Message sent by forum member 'cobrien' (cobrien)]
>> http://forums.java.net/jive/thread.jspa?messageID=267047
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>> For additional commands, e-mail: interest-help@jai-
>> imageio.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-
> imageio.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
|
|
|
|
|
|
|
|
|
Re: [JAI-IMAGEIO] Re: JAI IIO service provider list - Replacement
for ImageRead JPEG 12-bit
Posted:
Apr 1, 2008 10:30 AM
in response to: robert engels
|
|
|
Nope! It solved the problem and the watcher thread didn't cause the
OOM.
robert engels wrote:
> This won't really solve the problem - unless the action thread spawns a
> new process (JVM).
>
> Even though the action thread might be the one "causing" the OOM, the
> thread that runs out of memory may be the watcher thread - killing the
> watcher thread.
>
> This is detailed in the Java specification.
>
> There is a JSR underway to allow finer control of per thread memory
> use, and trapping of OOMs.
>
> On Apr 1, 2008, at 10:39 AM, Ken Warner wrote:
>
>> I had a similar problem. I had an out of memory exception generated
>> from
>> deep code I couldn't get to. So I wrote that action into a separate
>> thread and
>> then I wrote a watcher thread to watch the action thread and report
>> to my main
>> thread the state of the action thread. Then I put my main thread
>> into a loop
>> that would exit with a succeed or fail flag. So when the action
>> thread failed
>> the watcher thread kept running and reported the failure of the
>> action thread.
>>
>> Then the main thread just walked away from the whole mess unscathed
>> after taking
>> appropriate steps to clean up what it could.
>>
>> Works great. Now if I have a memory failure reading an image in my
>> applet, I
>> can recover well enough to report that failure to the user and give
>> information
>> on how to avoid that kind of failure in the future by raising the
>> memory limits
>> of the JVM.
>>
>> jai-imageio@javadesktop.org wrote:
>>
>>> Move the image processing out to a separate process. It's the only
>>> way to be sure that the overall application can ride out a JVM
>>> crash. That's what separate processes are for -- isolating memory
>>> spaces. We had to do this in a similar application, and it runs
>>> forever (well, a month since the last reboot and still running fine).
>>> [Message sent by forum member 'cobrien' (cobrien)]
>>> http://forums.java.net/jive/thread.jspa?messageID=267047
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>>> For additional commands, e-mail: interest-help@jai- imageio.dev.java.net
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>> For additional commands, e-mail: interest-help@jai- imageio.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
|
|
|
|
|
|
|
|
|
Re: [JAI-IMAGEIO] Re: JAI IIO service provider list - Replacement for ImageRead JPEG 12-bit
Posted:
Apr 1, 2008 8:35 PM
in response to: Ken Warner
|
|
|
It MAY work in your particular case, but it is not GUARANTEED to work.
If the watcher thread allocates ANY memory - which even if "your
code" doesn't, doesn't mean that a library method it calls doesn't -
a simple String allocation for instance - then the OOM can happen on
ANY thread - which could terminate the watcher thread (unless
properly coded to catch the OOM and handle appropriately). It the
action thread spawns another PROCESS (i.e. JVM) then this would not
be an issue.
This jsr covers features that will allow what you are "really trying
to do" - http://jcp.org/en/jsr/detail?id=284, but it is doubtful this
would ever work for native calls, as they have too much direct
control over the JVM data structures.
On Apr 1, 2008, at 12:30 PM, Ken Warner wrote:
> Nope! It solved the problem and the watcher thread didn't cause the
> OOM.
>
> robert engels wrote:
>> This won't really solve the problem - unless the action thread
>> spawns a new process (JVM).
>> Even though the action thread might be the one "causing" the OOM,
>> the thread that runs out of memory may be the watcher thread -
>> killing the watcher thread.
>> This is detailed in the Java specification.
>> There is a JSR underway to allow finer control of per thread
>> memory use, and trapping of OOMs.
>> On Apr 1, 2008, at 10:39 AM, Ken Warner wrote:
>>> I had a similar problem. I had an out of memory exception
>>> generated from
>>> deep code I couldn't get to. So I wrote that action into a
>>> separate thread and
>>> then I wrote a watcher thread to watch the action thread and
>>> report to my main
>>> thread the state of the action thread. Then I put my main
>>> thread into a loop
>>> that would exit with a succeed or fail flag. So when the action
>>> thread failed
>>> the watcher thread kept running and reported the failure of the
>>> action thread.
>>>
>>> Then the main thread just walked away from the whole mess
>>> unscathed after taking
>>> appropriate steps to clean up what it could.
>>>
>>> Works great. Now if I have a memory failure reading an image in
>>> my applet, I
>>> can recover well enough to report that failure to the user and
>>> give information
>>> on how to avoid that kind of failure in the future by raising
>>> the memory limits
>>> of the JVM.
>>>
>>> jai-imageio@javadesktop.org wrote:
>>>
>>>> Move the image processing out to a separate process. It's the
>>>> only way to be sure that the overall application can ride out a
>>>> JVM crash. That's what separate processes are for -- isolating
>>>> memory spaces. We had to do this in a similar application, and
>>>> it runs forever (well, a month since the last reboot and still
>>>> running fine).
>>>> [Message sent by forum member 'cobrien' (cobrien)]
>>>> http://forums.java.net/jive/thread.jspa?messageID=267047
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: interest-unsubscribe@jai-
>>>> imageio.dev.java.net
>>>> For additional commands, e-mail: interest-help@jai-
>>>> imageio.dev.java.net
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: interest-unsubscribe@jai-
>>> imageio.dev.java.net
>>> For additional commands, e-mail: interest-help@jai-
>>> imageio.dev.java.net
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>> For additional commands, e-mail: interest-help@jai-
>> imageio.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-
> imageio.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
|
|
|
|
|
|
|
|
|
Re: [JAI-IMAGEIO] Re: JAI IIO service provider list - Replacement
for ImageRead JPEG 12-bit
Posted:
Apr 1, 2008 10:31 AM
in response to: Ken Warner
|
|
|
It is a great idea. Ken, would you like to share your code?
Jie
Ken Warner wrote:
> I had a similar problem. I had an out of memory exception generated from
> deep code I couldn't get to. So I wrote that action into a separate
> thread and
> then I wrote a watcher thread to watch the action thread and report to
> my main
> thread the state of the action thread. Then I put my main thread into
> a loop
> that would exit with a succeed or fail flag. So when the action
> thread failed
> the watcher thread kept running and reported the failure of the action
> thread.
>
> Then the main thread just walked away from the whole mess unscathed
> after taking
> appropriate steps to clean up what it could.
>
> Works great. Now if I have a memory failure reading an image in my
> applet, I
> can recover well enough to report that failure to the user and give
> information
> on how to avoid that kind of failure in the future by raising the
> memory limits
> of the JVM.
>
> jai-imageio@javadesktop.org wrote:
>> Move the image processing out to a separate process. It's the only
>> way to be sure that the overall application can ride out a JVM crash.
>> That's what separate processes are for -- isolating memory spaces. We
>> had to do this in a similar application, and it runs forever (well, a
>> month since the last reboot and still running fine).
>> [Message sent by forum member 'cobrien' (cobrien)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=267047
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
|
|
|
|
|
|
|
|
|
Re: [JAI-IMAGEIO] Re: JAI IIO service provider list - Replacement
for ImageRead JPEG 12-bit
Posted:
Apr 1, 2008 2:48 PM
in response to: Jie Zhang
|
|
|
Disclaimer: This is not brilliant guru code. It just deals
with a particular problem that I had.
The code is so specific to the particular situation that
it wouldn't make any sense to you trying to apply it directly to
another situation. And note that this is not recovering
from a JVM crash as some have talked about. I don't see how
you can recover from a JVM crash for obvious reasons.
This just handles an OutOfMemoryException which shouldn't cause
your app/applet to hang forever.
The idea is real simple. Define a new anonymous Runnable that
does the action. Start the runable then loop watching the state of
your new action thread.
In this case, pg.grabPixels() starts another thread and my problem
was that the thread that pg.grabPixels() started would hang.
So pg.grabPixels() is the action thread and pgLoopCheck is the watcher thread
and the whole mess is spawned from another thread that you don't see here and then the applet is sitting above all of it.
private int width = 0;
private int height = 0;
public boolean KILLPGTHREAD = false;
private boolean getImageParametersAndPixels()
{
KILLPGTHREAD = false;
pixels = null;
System.gc();
Thread currentThread = null;
width = image.getWidth(canvas);
height = image.getHeight(canvas);
pixels = new int [width * height ];
pg = new PixelGrabber(image,0,0,width,height,pixels,0,width);
Runnable pgLoopCheck = new Runnable()
{
public void run()
{
try
{
while (pg.grabPixels(1000) != true);
{
System.err.println("Grabbing()...");
Thread.yield();
}
if ((pg.getStatus() & ImageObserver.ABORT) != 0)
{
System.err.println("Image fetch aborted or errored...");
}
}
catch (OutOfMemoryError oome)
{
System.err.println("(2)OutOfMemoryError:...");
}
catch(InterruptedException ie)
{
System.err.println("(2)InterruptedException:...");
}
catch (Throwable oome)
{
System.err.println("(2)Throwable:...");
//oome.printStackTrace();
}
Thread.yield();
}
};
Thread pgThread = new Thread(pgLoopCheck);
pgThread.start();
int status = 0;
Thread.State ts = null;
try
{
while((pgThread.isAlive()) && (!KILLPGTHREAD))
{
System.err.println("pgThread alive...");
status = pg.getStatus();
System.err.println("pixel grabber status = " + status);
ts = pgThread.getState();
System.err.println("thread state = " + ts.toString());
if ((status & ImageObserver.ABORT) != 0)
{
System.err.println("isAlive: image fetch aborted or errored");
pg.notify();
pgThread.notify();
}
if(pgThread.isInterrupted())
{
System.err.println("pgThread is interrupted...");
return false;
}
Thread.yield();
Thread.sleep(100);
}
System.err.println("Exiting isAlive() loop...");
}
catch (OutOfMemoryError oome)
{
System.err.println("(1)Throwable:...");
return false;
}
catch(InterruptedException ie)
{
System.err.println("(1)InterruptedException:...");
return false;
}
catch (Throwable oome)
{
System.err.println("(1)Throwable: ...");
//oome.printStackTrace();
return false;
}
return true;
}
Jie Zhang wrote:
> It is a great idea. Ken, would you like to share your code?
>
> Jie
> Ken Warner wrote:
>
>> I had a similar problem. I had an out of memory exception generated from
>> deep code I couldn't get to. So I wrote that action into a separate
>> thread and
>> then I wrote a watcher thread to watch the action thread and report to
>> my main
>> thread the state of the action thread. Then I put my main thread into
>> a loop
>> that would exit with a succeed or fail flag. So when the action
>> thread failed
>> the watcher thread kept running and reported the failure of the action
>> thread.
>>
>> Then the main thread just walked away from the whole mess unscathed
>> after taking
>> appropriate steps to clean up what it could.
>>
>> Works great. Now if I have a memory failure reading an image in my
>> applet, I
>> can recover well enough to report that failure to the user and give
>> information
>> on how to avoid that kind of failure in the future by raising the
>> memory limits
>> of the JVM.
>>
>> jai-imageio@javadesktop.org wrote:
>>
>>> Move the image processing out to a separate process. It's the only
>>> way to be sure that the overall application can ride out a JVM crash.
>>> That's what separate processes are for -- isolating memory spaces. We
>>> had to do this in a similar application, and it runs forever (well, a
>>> month since the last reboot and still running fine).
>>> [Message sent by forum member 'cobrien' (cobrien)]
>>>
>>> http://forums.java.net/jive/thread.jspa?messageID=267047
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>>> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
|
|
|
|
|
|
|
|
|
Re: [JAI-IMAGEIO] Re: JAI IIO service provider list - Replacement
for ImageRead JPEG 12-bit
Posted:
Apr 1, 2008 3:14 PM
in response to: Ken Warner
|
|
|
It is a good example. I basically get the idea.
Thanks,
Jie
Ken Warner wrote:
> Disclaimer: This is not brilliant guru code. It just deals
> with a particular problem that I had.
>
> The code is so specific to the particular situation that
> it wouldn't make any sense to you trying to apply it directly to
> another situation. And note that this is not recovering
> from a JVM crash as some have talked about. I don't see how
> you can recover from a JVM crash for obvious reasons.
>
> This just handles an OutOfMemoryException which shouldn't cause
> your app/applet to hang forever.
>
> The idea is real simple. Define a new anonymous Runnable that
> does the action. Start the runable then loop watching the state of
> your new action thread.
>
> In this case, pg.grabPixels() starts another thread and my problem was
> that the thread that pg.grabPixels() started would hang.
>
> So pg.grabPixels() is the action thread and pgLoopCheck is the watcher
> thread
> and the whole mess is spawned from another thread that you don't see
> here and then the applet is sitting above all of it.
>
> private int width = 0;
> private int height = 0;
> public boolean KILLPGTHREAD = false;
> private boolean getImageParametersAndPixels()
> {
> KILLPGTHREAD = false;
> pixels = null;
> System.gc();
> Thread currentThread = null;
> width = image.getWidth(canvas); height =
> image.getHeight(canvas);
> pixels = new int [width * height ];
> pg = new PixelGrabber(image,0,0,width,height,pixels,0,width);
> Runnable pgLoopCheck = new Runnable()
> {
> public void run()
> {
> try
> {
> while (pg.grabPixels(1000) != true);
> {
> System.err.println("Grabbing()...");
> Thread.yield();
> }
> if ((pg.getStatus() & ImageObserver.ABORT) != 0)
> {
> System.err.println("Image fetch aborted or
> errored...");
> }
> } catch
> (OutOfMemoryError oome)
> {
> System.err.println("(2)OutOfMemoryError:...");
> }
> catch(InterruptedException ie)
> {
> System.err.println("(2)InterruptedException:...");
> }
> catch (Throwable oome)
> {
> System.err.println("(2)Throwable:...");
> //oome.printStackTrace();
> } Thread.yield();
> }
> };
> Thread pgThread = new Thread(pgLoopCheck);
> pgThread.start();
> int status = 0;
> Thread.State ts = null;
> try
> {
> while((pgThread.isAlive()) && (!KILLPGTHREAD))
> {
> System.err.println("pgThread alive...");
> status = pg.getStatus();
> System.err.println("pixel grabber status = " + status);
> ts = pgThread.getState();
> System.err.println("thread state = " + ts.toString());
> if ((status & ImageObserver.ABORT) != 0) {
> System.err.println("isAlive: image fetch aborted or
> errored");
> pg.notify();
> pgThread.notify();
> }
> if(pgThread.isInterrupted())
> {
> System.err.println("pgThread is interrupted...");
> return false;
> }
> Thread.yield();
> Thread.sleep(100);
> }
> System.err.println("Exiting isAlive() loop...");
> }
> catch (OutOfMemoryError oome)
> {
> System.err.println("(1)Throwable:...");
> return false;
> } catch(InterruptedException ie)
> {
> System.err.println("(1)InterruptedException:...");
> return false;
> }
> catch (Throwable oome)
> {
> System.err.println("(1)Throwable: ...");
> //oome.printStackTrace();
> return false;
> } return true;
> }
>
> Jie Zhang wrote:
>> It is a great idea. Ken, would you like to share your code?
>>
>> Jie
>> Ken Warner wrote:
>>
>>> I had a similar problem. I had an out of memory exception generated
>>> from
>>> deep code I couldn't get to. So I wrote that action into a separate
>>> thread and
>>> then I wrote a watcher thread to watch the action thread and report
>>> to my main
>>> thread the state of the action thread. Then I put my main thread
>>> into a loop
>>> that would exit with a succeed or fail flag. So when the action
>>> thread failed
>>> the watcher thread kept running and reported the failure of the
>>> action thread.
>>>
>>> Then the main thread just walked away from the whole mess unscathed
>>> after taking
>>> appropriate steps to clean up what it could.
>>>
>>> Works great. Now if I have a memory failure reading an image in my
>>> applet, I
>>> can recover well enough to report that failure to the user and give
>>> information
>>> on how to avoid that kind of failure in the future by raising the
>>> memory limits
>>> of the JVM.
>>>
>>> jai-imageio@javadesktop.org wrote:
>>>
>>>> Move the image processing out to a separate process. It's the only
>>>> way to be sure that the overall application can ride out a JVM
>>>> crash. That's what separate processes are for -- isolating memory
>>>> spaces. We had to do this in a similar application, and it runs
>>>> forever (well, a month since the last reboot and still running fine).
>>>> [Message sent by forum member 'cobrien' (cobrien)]
>>>>
>>>> http://forums.java.net/jive/thread.jspa?messageID=267047
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>>>> For additional commands, e-mail:
>>>> interest-help@jai-imageio.dev.java.net
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>>> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
|
|
|
|
|
java.net RSS
