cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: Large xml's in cocoon
Date Fri, 28 May 2004 15:42:14 GMT
On 28 May 2004, at 15:28, Stefano Mazzocchi wrote:

> Antonio Gallardo wrote:
>> Stefano Mazzocchi dijo:
>>> Hmmm, Anna is right to report the problem though. I mean, why in 
>>> hell an
>>> OutOfMemoryException get swollen like that?
>> Not sure. I don't think we are swollen the exception in this case. 
>> But I
>> am not the best knowledge to tell that. ;-)
>> What I can said is: we have an application running since Cocoon 2.0.3 
>> and
>> has being updated on each Cocoon version to 2.1..5 and it works fine. 
>> We
>> render some reports to excel, html and pdf with more than 5,000 rows.
> I did experience the same "white page" error before and I feel that 
> was an OutOfMemoryException due to the JPEG thumbnail code (I was 
> creating 20 thumbnails at the same time from 4 megapixel images... I 
> guess the JVM heap was going insane).
> So, let's use heuristics here: did anybody ever see an 
> OutOfMemoryException in an cocoon error page? I haven't.
> Did you ever get a white page in cocoon that went away after one or 
> two reloads? I did.
> thoughts?

Ste, it's easy... I noticed several times that in OOMEs the stacktraces 
were all wrong as well... And I started to ask myself why...

Any time you do a catch (Throwable e) which (in theory) should also 
catch the OOME, you'll create an object, even maybe a silly one, like 
an exception wrapping the OOME, but, hey, you're out of memory, so, 
ANYTHING you do with that exception, apart from probably 
e.printStackTrace() will inevitably trigger another OOME...

I got around the problem by doing something like this:

try {
} catch (OutOfMemoryException exception) {
   // handle the OOME

but it doesn't always work...

I solved the problem by always piping my java standard output and error 
to a file, because being handled in the C code, that exception falls 
back to the bottom and (at the end) is dumped on your console...

But (for example) Tomcat's default startup scripts (or Jetty's for that 
matter) completely ignore the console (and that's why I always use my 
own builds of everything, most of the code out there is simply not 
ready "as is" to be deployed on production).

I mean, don't get me wrong, it's all very well written code, but until 
you don't hit a problem like a OOME on a real server, well, noone seems 
to care! :-P


View raw message