Home » Archived » BIRT » OutOfMemory JavaHeapSpace?
| OutOfMemory JavaHeapSpace? [message #91652] |
Wed, 16 November 2005 17:19  |
Eclipse User |
|
|
|
Originally posted by: jake.westviewclose.co.uk
All,
I've managed to rectify the looping issue in BIRT. It appears that when
rendering to a PDF the size of your fields can be tragically too big for
FOP to handle.
http://xmlgraphics.apache.org/fop/0.20.5/running.html
"There are currently some bugs which cause FOP to go into a
nonterminating loop, which will also often result in a memory overflow.
A characteristic symptom is continuous box overflows in the log. Most of
these loops are triggered by elements that do not fit in the available
space, such as big images or an improperly specified width in nested
block elements. The only workaround is to locate such problems and
correct them." - Quote from Apache.
However, i'm now hitting a JavaHeapSpace problem. I've got 1GB of RAM in
my PC and I'm setting the Eclipse program option as Xmx1024m
However, even though the entire report is only around 2MB...its blowing
the java heap space.
SEVERE: An OutOfMemory error happened while running FOP.
16-Nov-2005 17:10:37
org.eclipse.birt.report.engine.api.impl.RunAndRenderTask run
SEVERE: An OutOfMemory error happened while running the report.
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
Does anyone know if i can possibly fix this, or how i'd start the
RunandRenderTask with more available memory???
Please, if anyone can help it would be most appreciated, as i'm losing a
lot of hair..... :(
Thanks
jake
|
|
|
| Re: OutOfMemory JavaHeapSpace? [message #91682 is a reply to message #91652] |
Wed, 16 November 2005 20:05  |
 Kelvin Chu
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
Hi Jake,
It is an known issue of FOP. Since BIRT uses FOP, I also saw the same
"out of memory" of some very large reports in BIRT 1.0. BIRT development
team notices this issue and they have BPS 21
(http://www.eclipse.org/birt/wiki/index.php?n=BPS.BPS21) which will fix
this problem in BIRT 2.0.
Kelvin
Jake Day wrote:
> All,
>
> I've managed to rectify the looping issue in BIRT. It appears that when
> rendering to a PDF the size of your fields can be tragically too big for
> FOP to handle.
>
> http://xmlgraphics.apache.org/fop/0.20.5/running.html
>
> "There are currently some bugs which cause FOP to go into a
> nonterminating loop, which will also often result in a memory overflow.
> A characteristic symptom is continuous box overflows in the log. Most of
> these loops are triggered by elements that do not fit in the available
> space, such as big images or an improperly specified width in nested
> block elements. The only workaround is to locate such problems and
> correct them." - Quote from Apache.
>
> However, i'm now hitting a JavaHeapSpace problem. I've got 1GB of RAM in
> my PC and I'm setting the Eclipse program option as Xmx1024m
>
> However, even though the entire report is only around 2MB...its blowing
> the java heap space.
>
> SEVERE: An OutOfMemory error happened while running FOP.
> 16-Nov-2005 17:10:37
> org.eclipse.birt.report.engine.api.impl.RunAndRenderTask run
> SEVERE: An OutOfMemory error happened while running the report.
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>
> Does anyone know if i can possibly fix this, or how i'd start the
> RunandRenderTask with more available memory???
>
> Please, if anyone can help it would be most appreciated, as i'm losing a
> lot of hair..... :(
>
> Thanks
>
> jake
|
|
|
| Re: OutOfMemory JavaHeapSpace? [message #91741 is a reply to message #91682] |
Wed, 16 November 2005 22:00 |
| Eclipse User |
|
|
|
Originally posted by: jake.westviewclose.co.uk
Kelvin,
Thanks for getting back to me. Its good to know that BIRT 2.0 will fix
this issue. I've got three further questions that I'm hoping either you
or someone else may be able to answer from the back of this?
a) If I installed the prototype of BIRT 2.0 might this cure my problems,
or should i wait for the "production" version
b) How large is the "large" you refer too. My report is only around
180-200 pages (although it does have 7 nested tables)? Is this big? I
have no frame of reference?
c) Is there anything specifically that causes this massive memory usage.
(Specific fonts, italics, colours, defining fonts at cell level etc,
highlights?). I'm going to rebuild the report (again), and wondered if
anyone could enlighten me.
Again thanks for your response.
Jake
Kelvin Chu wrote:
> Hi Jake,
>
> It is an known issue of FOP. Since BIRT uses FOP, I also saw the same
> "out of memory" of some very large reports in BIRT 1.0. BIRT development
> team notices this issue and they have BPS 21
> (http://www.eclipse.org/birt/wiki/index.php?n=BPS.BPS21) which will fix
> this problem in BIRT 2.0.
>
> Kelvin
>
> Jake Day wrote:
>
>> All,
>>
>> I've managed to rectify the looping issue in BIRT. It appears that
>> when rendering to a PDF the size of your fields can be tragically too
>> big for FOP to handle.
>>
>> http://xmlgraphics.apache.org/fop/0.20.5/running.html
>>
>> "There are currently some bugs which cause FOP to go into a
>> nonterminating loop, which will also often result in a memory
>> overflow. A characteristic symptom is continuous box overflows in the
>> log. Most of these loops are triggered by elements that do not fit in
>> the available space, such as big images or an improperly specified
>> width in nested block elements. The only workaround is to locate such
>> problems and correct them." - Quote from Apache.
>>
>> However, i'm now hitting a JavaHeapSpace problem. I've got 1GB of RAM
>> in my PC and I'm setting the Eclipse program option as Xmx1024m
>>
>> However, even though the entire report is only around 2MB...its
>> blowing the java heap space.
>>
>> SEVERE: An OutOfMemory error happened while running FOP.
>> 16-Nov-2005 17:10:37
>> org.eclipse.birt.report.engine.api.impl.RunAndRenderTask run
>> SEVERE: An OutOfMemory error happened while running the report.
>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>>
>> Does anyone know if i can possibly fix this, or how i'd start the
>> RunandRenderTask with more available memory???
>>
>> Please, if anyone can help it would be most appreciated, as i'm losing
>> a lot of hair..... :(
>>
>> Thanks
>>
>> jake
|
|
|
| Re: OutOfMemory JavaHeapSpace? [message #93660 is a reply to message #91741] |
Tue, 22 November 2005 08:53 |
| Eclipse User |
|
|
|
Originally posted by: jake.westviewclose.co.uk
Hi all,
Just wondering if anyone had any views on the attached.
My biggest issue is still running out of memory. I've got 1GB of ram and
am starting my application with -Xmx1024M,
Yet the report is now only generating 40 pages before it blows the
heapspace. There must be something in my report that is using huge
chunks of memory, as the final reports are only 1MB, yet all the memory
is being used up when creating the report.
This is causing me serious headaches now as i'm having to put in all
sorts of "dodgy" code to handle reports between 35-45 pages and am
starting to suspect that i may have to find another report generation tool?
Can anyone advise what features might use up huge chunks of memory as
i've no idea what else to try now(i've got no charts and no images)?
Alternatively can anyone tell me how i can measure the levels of the
java heap as i can then remove pieces from my report to see if i can
identify if one part of the report is causing the problem.
Thanks kindly.
Jake
Jake Day wrote:
> Kelvin,
>
> Thanks for getting back to me. Its good to know that BIRT 2.0 will fix
> this issue. I've got three further questions that I'm hoping either you
> or someone else may be able to answer from the back of this?
>
>
> a) If I installed the prototype of BIRT 2.0 might this cure my problems,
> or should i wait for the "production" version
>
> b) How large is the "large" you refer too. My report is only around
> 180-200 pages (although it does have 7 nested tables)? Is this big? I
> have no frame of reference?
>
> c) Is there anything specifically that causes this massive memory usage.
> (Specific fonts, italics, colours, defining fonts at cell level etc,
> highlights?). I'm going to rebuild the report (again), and wondered if
> anyone could enlighten me.
>
> Again thanks for your response.
>
> Jake
>
> Kelvin Chu wrote:
>
>> Hi Jake,
>>
>> It is an known issue of FOP. Since BIRT uses FOP, I also saw the same
>> "out of memory" of some very large reports in BIRT 1.0. BIRT
>> development team notices this issue and they have BPS 21
>> (http://www.eclipse.org/birt/wiki/index.php?n=BPS.BPS21) which will
>> fix this problem in BIRT 2.0.
>>
>> Kelvin
>>
>> Jake Day wrote:
>>
>>> All,
>>>
>>> I've managed to rectify the looping issue in BIRT. It appears that
>>> when rendering to a PDF the size of your fields can be tragically too
>>> big for FOP to handle.
>>>
>>> http://xmlgraphics.apache.org/fop/0.20.5/running.html
>>>
>>> "There are currently some bugs which cause FOP to go into a
>>> nonterminating loop, which will also often result in a memory
>>> overflow. A characteristic symptom is continuous box overflows in the
>>> log. Most of these loops are triggered by elements that do not fit in
>>> the available space, such as big images or an improperly specified
>>> width in nested block elements. The only workaround is to locate such
>>> problems and correct them." - Quote from Apache.
>>>
>>> However, i'm now hitting a JavaHeapSpace problem. I've got 1GB of RAM
>>> in my PC and I'm setting the Eclipse program option as Xmx1024m
>>>
>>> However, even though the entire report is only around 2MB...its
>>> blowing the java heap space.
>>>
>>> SEVERE: An OutOfMemory error happened while running FOP.
>>> 16-Nov-2005 17:10:37
>>> org.eclipse.birt.report.engine.api.impl.RunAndRenderTask run
>>> SEVERE: An OutOfMemory error happened while running the report.
>>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>>>
>>> Does anyone know if i can possibly fix this, or how i'd start the
>>> RunandRenderTask with more available memory???
>>>
>>> Please, if anyone can help it would be most appreciated, as i'm
>>> losing a lot of hair..... :(
>>>
>>> Thanks
>>>
>>> jake
|
|
|
| Re: OutOfMemory JavaHeapSpace? [message #95043 is a reply to message #93660] |
Tue, 29 November 2005 09:05 |
Frédéric Ferrant
Messages: 75
Registered: July 2009 |
Member |
|
|
Hello Jake,
we have the same problem with a 10 pages report using many datasets
(more than 20). Since we can't solve the problem, we are currently
considering the generation of HTML instead of PDF...
If you have anything new, we are greatly interested too...
On Tue, 22 Nov 2005 08:53:48 +0000, Jake Day
<jake@westviewclose.co.uk> wrote:
>Hi all,
>
>Just wondering if anyone had any views on the attached.
>
>My biggest issue is still running out of memory. I've got 1GB of ram and
>am starting my application with -Xmx1024M,
>
>Yet the report is now only generating 40 pages before it blows the
>heapspace. There must be something in my report that is using huge
>chunks of memory, as the final reports are only 1MB, yet all the memory
>is being used up when creating the report.
>
>This is causing me serious headaches now as i'm having to put in all
>sorts of "dodgy" code to handle reports between 35-45 pages and am
>starting to suspect that i may have to find another report generation tool?
>
>Can anyone advise what features might use up huge chunks of memory as
>i've no idea what else to try now(i've got no charts and no images)?
>
>Alternatively can anyone tell me how i can measure the levels of the
>java heap as i can then remove pieces from my report to see if i can
>identify if one part of the report is causing the problem.
>
>Thanks kindly.
>
>Jake
|
|
|
| Re: OutOfMemory JavaHeapSpace? [message #95265 is a reply to message #95043] |
Tue, 29 November 2005 17:12 |
| Eclipse User |
|
|
|
Originally posted by: jake.westviewclose.co.uk
Frederic,
It's sort of good to know that at least someone else out there is having
the same issues.....
Unfortunately I haven't yet found an answer to the problem. I have no
idea what is so memory intensive, but when the final report is less than
1MB(around 400KB seems to be the biggest report i can produce) i can't
really understand why the report generation should blow a 1GB heap.
I still assume that it is FOP that is blowing the memory, but have no
idea how to break this usage down
I have no idea how to get round this issue, so have resorted to breaking
down my reports into smaller (30-40 page) chunks.
I'm also going to investigate rationalising the data (i'm currently
using 18 datasources and might be able to reduce this to 10-12) this may
make a difference.
My second strategy is to start all over again with another tool (jaspar
reports or something like that?).
I'll let you know if i discover any radical reason for the massive heap,
and please it would be most appreciated if you could do the same.
Jake
Frederic Ferrant wrote:
> Hello Jake,
>
> we have the same problem with a 10 pages report using many datasets
> (more than 20). Since we can't solve the problem, we are currently
> considering the generation of HTML instead of PDF...
>
> If you have anything new, we are greatly interested too...
>
>
>
> On Tue, 22 Nov 2005 08:53:48 +0000, Jake Day
> <jake@westviewclose.co.uk> wrote:
>
>
>>Hi all,
>>
>>Just wondering if anyone had any views on the attached.
>>
>>My biggest issue is still running out of memory. I've got 1GB of ram and
>>am starting my application with -Xmx1024M,
>>
>>Yet the report is now only generating 40 pages before it blows the
>>heapspace. There must be something in my report that is using huge
>>chunks of memory, as the final reports are only 1MB, yet all the memory
>>is being used up when creating the report.
>>
>>This is causing me serious headaches now as i'm having to put in all
>>sorts of "dodgy" code to handle reports between 35-45 pages and am
>>starting to suspect that i may have to find another report generation tool?
>>
>>Can anyone advise what features might use up huge chunks of memory as
>>i've no idea what else to try now(i've got no charts and no images)?
>>
>>Alternatively can anyone tell me how i can measure the levels of the
>>java heap as i can then remove pieces from my report to see if i can
>>identify if one part of the report is causing the problem.
>>
>>Thanks kindly.
>>
>>Jake
|
|
|
| Re: OutOfMemory JavaHeapSpace? [message #95690 is a reply to message #95265] |
Wed, 30 November 2005 13:50 |
Frédéric Ferrant
Messages: 75
Registered: July 2009 |
Member |
|
|
Jake,
We use scripted datasource to pass data to the reports... It seems
like scripted datasources have a memory leak problem (see bugzilla bug
113198: https://bugs.eclipse.org/bugs/), so this might be a part of
the problem (in my case).
I also read that the PDF generation by FOP could cause other memory
problems, so I am waiing for version 2.0 which plans another PDF
emitter.
As I said before, we tried generating HTML, but it also leads to
memory problems (after a while), I guess this is due to the scripted
datasources.
Have a nice day.
Frederic.
On Tue, 29 Nov 2005 17:12:00 +0000, Jake Day
<jake@westviewclose.co.uk> wrote:
>Frederic,
>
>It's sort of good to know that at least someone else out there is having
>the same issues.....
>
>Unfortunately I haven't yet found an answer to the problem. I have no
>idea what is so memory intensive, but when the final report is less than
> 1MB(around 400KB seems to be the biggest report i can produce) i can't
>really understand why the report generation should blow a 1GB heap.
>
>I still assume that it is FOP that is blowing the memory, but have no
>idea how to break this usage down
>
>I have no idea how to get round this issue, so have resorted to breaking
>down my reports into smaller (30-40 page) chunks.
>
>I'm also going to investigate rationalising the data (i'm currently
>using 18 datasources and might be able to reduce this to 10-12) this may
>make a difference.
>
>My second strategy is to start all over again with another tool (jaspar
>reports or something like that?).
>
>I'll let you know if i discover any radical reason for the massive heap,
>and please it would be most appreciated if you could do the same.
>
>Jake
|
|
|
| Re: OutOfMemory JavaHeapSpace? [message #96785 is a reply to message #95690] |
Tue, 06 December 2005 12:25 |
Frédéric Ferrant
Messages: 75
Registered: July 2009 |
Member |
|
|
More info about the memory leak when using scripted datasets:
When performing tests to trace the cause of our problematic behaviour,
we noticed the following:
An object of type org.eclipse.birt.data.engine.script.ScriptUtil
remains in the Heap, and contains a HashMap. The contents of this
HashMap seems to grow each time we generate a pdf or a html.
Since we use scripted datasets, my first thought was that the lines of
javascript code used in the 'open', 'fetch' and 'close' methods of the
scriptedDatasets where stored in that HashMap.
To make sure this assertion was correct, I added large comments zones
in a rptdesign (the initial rptdesign size was about 300 Kb, the
modified was 1Mb). These comments (/* long blabla */) where added in
several 'open' and 'fetch' methods.
With the normal version of the rptdesign file, our server is out of
memory after generation of 137 reports.
With the 'heavy' version, it is out of memory after only 9 reports...
To make sure this wasn't just liked to the size of the rptdesign file
itself, I made the same test adding 1500 styles to the report, which
also increased the size of the rptdesign file to about 1Mb, but didn't
lead to memory problems (at least not so fast: we could generate more
than 100 reports)...
I'll try the 2.0M3 version which is now downloadable (but I didn't
read about any correction for this bug), and I'll try to run through
the SciptUtil code in debug-mode, if I can notice anything else...
Have a nice day.
|
|
|
| Info for Bugzilla Bug 113198 - (RE: OutOfMemory JavaHeapSpace?) [message #98428 is a reply to message #96785] |
Mon, 12 December 2005 09:23 |
Frédéric Ferrant
Messages: 75
Registered: July 2009 |
Member |
|
|
The memory problem reported by Jake and myself maybe isn't linked to
FOP... I had the same memory problem generating HTML with scripted
datasources...
I think we found the cause of the memory leak in ScriptUtil.java...
We (locally) modified the 1.0.1 version of ScriptUtil.java to solve
our memory problem.
First, we removed the line 'registeredScript.clear();' line in the
'getTailoredScript' method.
We are not sure about the effects of this removal, since we can't
figure out what the 'scope' is, but if we don't do this, the
registeredScript Map gets cleared every time we run through the
method, and the tailoredScript map grows undefinitely.
We also changed the line
'registeredScript.put(originalScript, functionName + "();");'
to
'registeredScript.put(originalScript,tailoredScript);'
since the map seems to hold the tailoredScript.
Have a nice day.
On Tue, 06 Dec 2005 13:25:08 +0100, Frederic Ferrant
<frederic@ferrant.be> wrote:
>More info about the memory leak when using scripted datasets:
>
>When performing tests to trace the cause of our problematic behaviour,
>we noticed the following:
>An object of type org.eclipse.birt.data.engine.script.ScriptUtil
>remains in the Heap, and contains a HashMap. The contents of this
>HashMap seems to grow each time we generate a pdf or a html.
>
>Since we use scripted datasets, my first thought was that the lines of
>javascript code used in the 'open', 'fetch' and 'close' methods of the
>scriptedDatasets where stored in that HashMap.
>To make sure this assertion was correct, I added large comments zones
>in a rptdesign (the initial rptdesign size was about 300 Kb, the
>modified was 1Mb). These comments (/* long blabla */) where added in
>several 'open' and 'fetch' methods.
>
>With the normal version of the rptdesign file, our server is out of
>memory after generation of 137 reports.
>With the 'heavy' version, it is out of memory after only 9 reports...
>
>To make sure this wasn't just liked to the size of the rptdesign file
>itself, I made the same test adding 1500 styles to the report, which
>also increased the size of the rptdesign file to about 1Mb, but didn't
>lead to memory problems (at least not so fast: we could generate more
>than 100 reports)...
>
>I'll try the 2.0M3 version which is now downloadable (but I didn't
>read about any correction for this bug), and I'll try to run through
>the SciptUtil code in debug-mode, if I can notice anything else...
>
>Have a nice day.
|
|
|
Goto Forum:
Current Time: Sat Nov 09 05:47:49 GMT 2024
Powered by FUDForum. Page generated in 0.04354 seconds |
] 
Search
Help
Register
Login
Home
