Antonio,

I tried to remove the workaround. Initially I was very happy, because it seemed to work much better.

Soon the image crashing behaviour resumed though.

It seems that JPEG decoders themselves leak memory(or something to that effect).

My tomcat goes from 97 mb to 115 mb, according to top. When this happens tomcat throws a "OutOfMemory" exception,
but continues working. Cocoon then gets a "truncatedfile" exception in the image routines.


After a while the system recovers and can generate a couple of more thumbnails.

If the cocoon pooling system for the image reader works properly, as Vadim suggested, there should never
be more than 2 image buffers active in my case. So out of memory should never occur if theres no leak.


I will try to rewrite the scaling code to use the newer javax.imageio/JAI apis instead. Maybe they work better.

Thanks also for the 1.4 identification code.

Regards,
/Joakim

Antonio Gallardo wrote:

OK. I got it.

Lets try your solution and if this work. I will fix the CVS. :-D

While you make the test I will find the java property that allow to check
the version of Java. OK?

Bets Regards,

Antonio Gallardo

Joakim Verona dijo:


Hi Antonio, thanks for your effort, I appreciate it.

I made a mistake in my list, I'm in fact using j2sdk 1.4.2_02 already.

I read the comment also, and since it said "workaround will
automagically go away" I assumed it would :-)
Maybe you are right and I should try without the workaround.

Do you know if there is a JDK version configuration flag somewhere in
the build scripts one could use?

Heres the original code:

               JPEGImageDecoder decoder =
JPEGCodec.createJPEGDecoder(inputStream);
               Raster original = decoder.decodeAsRaster();
               JPEGDecodeParam decodeParam =
decoder.getJPEGDecodeParam();
               double ow = decodeParam.getWidth();
               double oh = decodeParam.getHeight();
               AffineTransformOp filter = new
AffineTransformOp(getTransform(ow, oh, width, height),
AffineTransformOp.TYPE_BILINEAR);
               WritableRaster scaled =
filter.createCompatibleDestRaster(original);
               filter.filter(original, scaled);


// JPEGImageEncoder encoder = JPEGCodec.createJPEGEncoder(out);


ByteArrayOutputStream bstream = new ByteArrayOutputStream(); JPEGImageEncoder encoder = JPEGCodec.createJPEGEncoder(bstream); encoder.encode(scaled); out.write(bstream.toByteArray());


I think this should remove the workaround:


               JPEGImageDecoder decoder =
JPEGCodec.createJPEGDecoder(inputStream);
               Raster original = decoder.decodeAsRaster();
               JPEGDecodeParam decodeParam =
decoder.getJPEGDecodeParam();
               double ow = decodeParam.getWidth();
               double oh = decodeParam.getHeight();
               AffineTransformOp filter = new
AffineTransformOp(getTransform(ow, oh, width, height),
AffineTransformOp.TYPE_BILINEAR);
               WritableRaster scaled =
filter.createCompatibleDestRaster(original);
               filter.filter(original, scaled);


JPEGImageEncoder encoder = JPEGCodec.createJPEGEncoder(out);


// // ByteArrayOutputStream bstream = new ByteArrayOutputStream(); // // JPEGImageEncoder encoder = JPEGCodec.createJPEGEncoder(bstream); encoder.encode(scaled); // // out.write(bstream.toByteArray());

I will try this, it seems simple enough.

When you think about it you can see that the workaround code is very
memory hungry(as SM says in his comment)
For each incomming concurrent request it has to buffer the entire image
before writing.

Regards,
Joakim

Antonio Gallardo wrote:



Joakim Verona dijo:




Thanks Antonio,




Hi Joakim:

First, I never used the image reader. But I am trying to help you.

I saw at the sources of ImageReader and from the comment inside the code
I
saw currently there is a workaround for Java version lower than 1.4. Also
a comment stating that the bug is not prsent in 1.4. For this reason, I
think we can introduce a JVM switch and allow 1.4 to make the processing
without the mentioning workaround that seems to be buggy (based on yours
experiences).

(SM) are the Initial of the committer who included the comments, problem
is I don't know if he is Stefano or Stephan. :-(

I think we can ask them directly and suggest them about a special code
for
1.4

What you think?

Also I never tried Tomcat 5.16.
Can you upgrade to Java 1.4.2_02?

Best Regards,

Antonio Gallardo





Heres my plattform specification:

Dual athlon 800 megs of ram
Redhat 9
Sun JDK 1.4.1.02
Tomcat 5.16
cocoon 2.1.3

So its a fairly up-to-date setup.

Originally I used older versions, but in order to try to solve the
problem I upgraded all relevant components I could think of.

What bugs me is that i can't find any references to anyone else
experiencing this.
This should either be because my setup is unusual(no) or that nobody is
using the imagereader this way.
The later shouldn't be true eiterh, since I use a small number of fairly
small files, say 16 2mbyte jpegs.

Maybe the Suns Java 2D components native parts have some scarce
resources or something, or maybe the problem isn�t in the ImageReader at
all, but in the underlying file reader components.

Regards,
/Joakim

Antonio Gallardo wrote:





Hi Joakim:

Can you provide your platform? Maybe the problem is there.

Best Regards,

Antonio Gallardo


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to