You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Joakim Verona <jo...@verona.se> on 2003/12/05 17:12:59 UTC
instability of cocoon image reader?
Hello list,
I'm writing a simple photo browser with the cocoon image reader and
image directory generator.
It seems the image reader is unstable when generating thumbnails.
Random images get broken, that is, the image reader doesnt generate the
thumbnails properly.
I guess the problem is that a lot of thumbnails are requested at the
same time from the server, since the thumbnail table is generated first,
and the thumbnails img tags request from the server all at once.
Is there any way around this?
I would think that the proper way for cocoon to handle this is to block
new thumbail request over a certain maximum if it cant handle it, rather
than just generating nothing at all.
(incidentally I wrote a jsp version of an image browser some time ago,
and it had the same problem when generating thumbnails)
Regards,
/Joakim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: instability of cocoon image reader?
Posted by Joakim Verona <jo...@verona.se>.
Geoff,
I'm running cocoon in a tomcat 5 caontainer using the default startup
values.
I'm not shure how much heap this is by default.
It seems the tomcat java process requires 113 mb right now.
Im running cocoon 2.1.3, tomcat 5, redhat 9.
Regards,
/Joakim
Geoff Howard wrote:
> Joakim Verona wrote:
>
>> Hello list,
>>
>> I'm writing a simple photo browser with the cocoon image reader and
>> image directory generator.
>>
>> It seems the image reader is unstable when generating thumbnails.
>> Random images get broken, that is, the image reader doesnt generate
>> the thumbnails properly.
>>
>> I guess the problem is that a lot of thumbnails are requested at the
>> same time from the server, since the thumbnail table is generated
>> first, and the thumbnails img tags request from the server all at once.
>>
>> Is there any way around this?
>>
>> I would think that the proper way for cocoon to handle this is to
>> block new thumbail request over a certain maximum if it cant handle
>> it, rather than just generating nothing at all.
>>
>> (incidentally I wrote a jsp version of an image browser some time
>> ago, and it had the same problem when generating thumbnails)
>
>
> How much memory are you giving it?
>
> Geoff
>
>
> ---------------------------------------------------------------------
> 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
Re: instability of cocoon image reader?
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Antonio Gallardo dijo:
> 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?
Hi Joakim:
I found a System property called
java.specification.version=1.4
We can make use of it as follow:
if "1.4".equals(System.getProperty("java.specification.version"))
{
// Here code for 1.4
} else {
// Here code for 1.3
}
Even better we can define a boolean variable "isJava14" at the startup
that just set a boolean and then test as above but using it. That way we
don't need to "read" every time the property.
Is this OK?
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: instability of cocoon image reader?
Posted by joakim verona <jo...@verona.se>.
Antonio,
>Hmm....
>
>
>>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.
>>
>>
>
>Are you tried allow Tomcat to use more memory? Maybe you need to play with
>some switches inside Tomcat. The same apply when you are using FOP.
>
>Maybe if you increase the memory for Tomcat it would be able to render
>more images at once. Can you make the test of it?
>
>
Yes, I will test, but I have to figure out the correct switches first.
Maybe it will work if I allocate enough memory, but it doesn't seem right.
"OutOfMemory" should only be thrown after garbage collect, and I can't
see why
if I have only two ImageReaders configured, it will eat more memory than
needed to
scale two images. It feels like theres memory leakage, and if so, it
will never be robust.
Or is the cocoon pooling mechanism not working in this case? Do you have
to do anything special
in a cocoon poolable class that might have been missed?
How do you debug memoy problems in Java anyway? With C/C++ development
there's
Valgrind and all sorts of cool tools.
Regards,
/Joakim
>
>
>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
Re: instability of cocoon image reader?
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Hi Joakim,
I am glad to hear it is better, but still not the best.
joakim verona dijo:
> 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).
Hmm....
>
> 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.
Are you tried allow Tomcat to use more memory? Maybe you need to play with
some switches inside Tomcat. The same apply when you are using FOP.
Maybe if you increase the memory for Tomcat it would be able to render
more images at once. Can you make the test of it?
> 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
>
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: instability of cocoon image reader?
Posted by joakim verona <jo...@verona.se>.
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
Re: instability of cocoon image reader?
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
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
Re: instability of cocoon image reader?
Posted by Joakim Verona <jo...@verona.se>.
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
Re: instability of cocoon image reader?
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
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
Re: instability of cocoon image reader?
Posted by Joakim Verona <jo...@verona.se>.
Thanks Antonio,
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
Re: instability of cocoon image reader?
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
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
Re: instability of cocoon image reader?
Posted by Joakim Verona <jo...@verona.se>.
Well, I'm trying obviously...
I've read the sources, and indeed the transform part is fairly
understandable.
Why this simple soulution would croak just because it receives a small
number of concurrent requests is
not completely obvious.
/Joakim
Vadim Gritsenko wrote:
> joakim verona wrote:
>
>> Vadim,
>>
>> Thanks again, but I'm still scratching my head.
>>
>> I have tried numerous values for the different pool parameters,
>> including grow=0, and max/min=1.
>>
>> The basic problem remains.
>
>
>
> Then dig deeper... ImageReader is not that complex, you write some
> load tests based on it and see where/why it fails.
>
> Vadim
>
>
>
> ---------------------------------------------------------------------
> 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
Re: instability of cocoon image reader?
Posted by Vadim Gritsenko <va...@verizon.net>.
joakim verona wrote:
> Vadim,
>
> Thanks again, but I'm still scratching my head.
>
> I have tried numerous values for the different pool parameters,
> including grow=0, and max/min=1.
>
> The basic problem remains.
Then dig deeper... ImageReader is not that complex, you write some load
tests based on it and see where/why it fails.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: instability of cocoon image reader?
Posted by joakim verona <jo...@verona.se>.
Vadim,
Thanks again, but I'm still scratching my head.
I have tried numerous values for the different pool parameters,
including grow=0, and max/min=1.
The basic problem remains.
/Joakim
Vadim Gritsenko wrote:
> joakim verona wrote:
>
>> Vadim,
>>
>> Thanks for your tip. It seems it works a little better with reducing
>> the pool, but the problem still remains.
>>
>> Heres the modified imagereader component definition:
>>
>> <map:reader name="image"
>> src="org.apache.cocoon.reading.ImageReader"
>> logger="sitemap.reader.image"
>> pool-max="2"
>> pool-min="1"
>> pool-grow="1"/>
>> </map:readers>
>>
>> It still craches, but manages to generate more thumbnails.
>
>
>
> If you re-read my response, I wrote "I'd recommend hard-limiting the
> pool". That would translate to pool-grow="0", I think. Try:
>
> <map:reader name="image"
> src="org.apache.cocoon.reading.ImageReader"
> logger="sitemap.reader.image"
> pool-max="5"
> pool-min="5"
> pool-grow="0"/>
>
>
> Vadim
>
>
>
> ---------------------------------------------------------------------
> 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
Re: instability of cocoon image reader?
Posted by Vadim Gritsenko <va...@verizon.net>.
joakim verona wrote:
> Vadim,
>
> Thanks for your tip. It seems it works a little better with reducing
> the pool, but the problem still remains.
>
> Heres the modified imagereader component definition:
>
> <map:reader name="image"
> src="org.apache.cocoon.reading.ImageReader"
> logger="sitemap.reader.image"
> pool-max="2"
> pool-min="1"
> pool-grow="1"/>
> </map:readers>
>
> It still craches, but manages to generate more thumbnails.
If you re-read my response, I wrote "I'd recommend hard-limiting the
pool". That would translate to pool-grow="0", I think. Try:
<map:reader name="image"
src="org.apache.cocoon.reading.ImageReader"
logger="sitemap.reader.image"
pool-max="5"
pool-min="5"
pool-grow="0"/>
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: instability of cocoon image reader?
Posted by joakim verona <jo...@verona.se>.
Vadim,
Thanks for your tip. It seems it works a little better with reducing the
pool, but the problem still remains.
Heres the modified imagereader component definition:
<map:reader name="image"
src="org.apache.cocoon.reading.ImageReader"
logger="sitemap.reader.image"
pool-max="2"
pool-min="1"
pool-grow="1"/>
</map:readers>
It still craches, but manages to generate more thumbnails.
Here is the exception in the cocoon handled-errors.log:
com.sun.image.codec.jpeg.TruncatedFileException: Premature end of input file
I agree that cached thumbnails would be better in many ways,
but for various reasons it wouldnt be very convenient in my case.
/Joakim
Vadim Gritsenko wrote:
> Geoff Howard wrote:
>
>> Joakim Verona wrote:
>>
>>> Hello list,
>>>
>>> I'm writing a simple photo browser with the cocoon image reader and
>>> image directory generator.
>>>
>>> It seems the image reader is unstable when generating thumbnails.
>>> Random images get broken, that is, the image reader doesnt generate
>>> the thumbnails properly.
>>>
>>> I guess the problem is that a lot of thumbnails are requested at the
>>> same time from the server, since the thumbnail table is generated
>>> first, and the thumbnails img tags request from the server all at once.
>>>
>>> Is there any way around this?
>>
>>
>
> Reader is recyclable. I'd recommend hard-limiting the pool of image
> readers to the number low enough so server can handle this amount of
> request, and even two or three less then that.
>
> (but personally speaking, I'd never do thumbnail generation on the
> fly. especially given this low prices on 6.3mpixel cameras. offline
> generation is the way to go)
>
> Vadim
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: instability of cocoon image reader?
Posted by Vadim Gritsenko <va...@verizon.net>.
Geoff Howard wrote:
> Joakim Verona wrote:
>
>> Hello list,
>>
>> I'm writing a simple photo browser with the cocoon image reader and
>> image directory generator.
>>
>> It seems the image reader is unstable when generating thumbnails.
>> Random images get broken, that is, the image reader doesnt generate
>> the thumbnails properly.
>>
>> I guess the problem is that a lot of thumbnails are requested at the
>> same time from the server, since the thumbnail table is generated
>> first, and the thumbnails img tags request from the server all at once.
>>
>> Is there any way around this?
>
Reader is recyclable. I'd recommend hard-limiting the pool of image
readers to the number low enough so server can handle this amount of
request, and even two or three less then that.
(but personally speaking, I'd never do thumbnail generation on the fly.
especially given this low prices on 6.3mpixel cameras. offline
generation is the way to go)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: instability of cocoon image reader?
Posted by Geoff Howard <co...@leverageweb.com>.
Joakim Verona wrote:
> Hello list,
>
> I'm writing a simple photo browser with the cocoon image reader and
> image directory generator.
>
> It seems the image reader is unstable when generating thumbnails.
> Random images get broken, that is, the image reader doesnt generate the
> thumbnails properly.
>
> I guess the problem is that a lot of thumbnails are requested at the
> same time from the server, since the thumbnail table is generated first,
> and the thumbnails img tags request from the server all at once.
>
> Is there any way around this?
>
> I would think that the proper way for cocoon to handle this is to block
> new thumbail request over a certain maximum if it cant handle it, rather
> than just generating nothing at all.
>
> (incidentally I wrote a jsp version of an image browser some time ago,
> and it had the same problem when generating thumbnails)
How much memory are you giving it?
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org