cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From joakim verona <joa...@verona.se>
Subject Re: instability of cocoon image reader?
Date Mon, 08 Dec 2003 22:47:08 GMT
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: users-unsubscribe@cocoon.apache.org
>>>>>For additional commands, e-mail: users-help@cocoon.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>>>For additional commands, e-mail: users-help@cocoon.apache.org
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>>For additional commands, e-mail: users-help@cocoon.apache.org
>>>
>>>
>>>      
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message