SERPland Flugverkehr/Airtraffic Zürich – Auto Direktimport Dänemark – Disneyland Paris – Legoland Deutschland

13Feb/073

Oracle Reports: Long running PDF Report crashes (rw.dll)


Target: Oracle Report should generate > 13000 pages of PDF output.
This is a long running report around 15 Minutes.
Is a Oracle report with paper layout.
Works perfect when pressing "run paper layout" in Oracle Reports Builder 10g (10.1.2.0.2)
Can scroll down to pag 13000.
Now I'd like to create a 13000 page pdf file.
Reports Developer Menu - FILE - GENERATE TO FILE - PDF
Report ist starting and counting up to something between 400 and 9000 pages - and then crashes.
The same behavior when doing it directly in Reports Developer as when depolyed on
OAS Reports Services.

Error Log :

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x65125621
Function=rwagrcm+0x51521
Library=C:\orant_10gR2\BIN\rw.dll

Current Java thread:
at oracle.reports.engine.EngineImpl.CRunReport(Native Method)
at oracle.reports.engine.EngineImpl.run(EngineImpl.java:437)
at oracle.reports.server.JobManager.runJobInEngine(JobManager.java:916)
- locked <0x11574a08> (a oracle.reports.engine.EngineImpl)
at oracle.reports.server.ExecAsynchJobThread.run(ExecAsynchJobThread.java:54)

...
...
...

Heap at VM Abort:
Heap
def new generation total 1344K, used 1227K [0x10030000, 0x101a0000, 0x113e0000)
eden space 1216K, 94% used [0x10030000, 0x1014fa78, 0x10160000)
from space 128K, 59% used [0x10160000, 0x101732c8, 0x10180000)
to space 128K, 0% used [0x10180000, 0x10180000, 0x101a0000)
tenured generation total 17012K, used 15998K [0x113e0000, 0x1247d000, 0x20030000)
the space 17012K, 94% used [0x113e0000, 0x1237fa28, 0x1237fc00, 0x1247d000)
compacting perm gen total 17408K, used 17308K [0x20030000, 0x21130000, 0x24030000)
the space 17408K, 99% used [0x20030000, 0x211173a8, 0x21117400, 0x21130000)


Solution 1:a) make the following change:
b) open the rwbuilder configuration file located in:

DEVELOPER_SUITE_HOME\reports\conf\rwbuilder.conf

c) search for the following entry:

and replace the value="50" with a value that should be larger that the report output will be generated. (the value is in Mb)

d) restart the Reports Builder in order that the change will take effect .


Solution 2:a). locate the rwbuilder configuration file in:
DEVELOPER_SUITE_HOME\reports\conf\rwbuilder.conf and search for the
id="rwEng" ../>tag.b). Add the following attributes to the engine tag:
jvmOptions="-Xms1024m -Xmx1024m"for example
Change from

maxEngine="1" minEngine="0" engLife="50" maxIdle="30" callbackTimeOut="60000">

into

maxEngine="1" minEngine="0" engLife="50" maxIdle="30" callbackTimeOut="60000"
jvmOptions="-Xms512m -Xmx512m">
This will set an Engine's JVM options.

c). restart the report builder

( Alternate try to suppose this as a Oracle Reports command line extention as:
C:\orant_10gR2\BIN\rwbuilder.exe jvmoptions="-Xmx1024m -XX:+PrintGCDetail" )


Solution 3:I think the problem is somewhere in the PermSize section of Java / JVM
I found an interesting link : http://forums.bea.com/bea/message.jspa?messageID=202465135&tstart=0 Afther that I started my report with:
C:\orant_10gR2\BIN\rwbuilder.exe jvmoptions="-Xmx1024m -XX:+PrintGCDetail"
With this I tried getting more error information.
But what happend?
Beleve it or not. Now, my Report run successfully and created 13000 pdf pages.I will further investigate with jvmoptions:
-XX:NewSize=128m -XX:MaxNewSize=128m -XX:PermSize=64m -XX:MaxPermSize=64m


Additional information belonging to this Oracle Reports Bug (Java Problem, JVM):
I would bet you run out of permspace:
compacting perm gen total 9472K, used 9414K [0x30010000, 0x30950000, 0x34010000)
the space 9472K, 99% used [0x30010000, 0x30941a30, 0x30941c00, 0x30950000)I think low space is the problem, but I don't know how to increase it... (I use the Eclipse platform)I solve the problem in desactivating the Hotspot mode with the option -Xint.The JVM options used are - maxpermsize 128M, xMs - 512M and xMx - 512M.The PERMANENT heap NEVER will reduce and in fact objects (Classes) placed in the PERMANENT heap are PERMANENTLY in that HEAP. Hence PERMANENT. No GC will ever unload any object from the permanent heap.When the perm gen is full, the classes would be unloaded from perm gen. And that is happening in my case also. The log file shows in some other cases when the perm gen size reaches some value of 46-47MB - the classes getting unloaded.

This is my currently VM options:
-Xms256m -Xmx256m -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintGCApplicationStoppedTime -XX:NewSize=64M -XX:MaxNewSize=64M -XX:SurvivorRatio=8 -Xloggc:/logs/weblogic/jdevext/gc.log

The key parameters that you can send to the JVM are summarized below:
* -verbose:gc - Prints some GC info
* -XX:+PrintGCDetails - PrintGC details
* -XX:+PrintGCTimeStamps - Adds timestamp info to GC details
* -XX:+PrintHeapAtGC - Prints detailed GC info including heap occupancy before and after GC
* -XX:+PrintTenuringDistribution - Prints object aging or tenuring information
* -XX:+PrintHeapUsageOverTime - Print heap usage and capacity with timestamps
* -Xloggc:filename - Prints GC info to a log file

MaxPermSize ??
if Perm Size is in a separate area, are we saying that there should be a formula like: MaxNewSize+MaxPermSize=max heap size?
-ms512m -mx512m -XX:MaxPermSize=64m

Please try setting PermSize to the same value as MaxPermSize when you run the test.
-Xms512m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=64m

- The permanent space is memory allocated outside the regular heap (i.e. in addition to the -Xmx setting), so it is important to ensure there is enough physical RAM on the machine. The permanent space is used to primarily store classes and objects created for reflection support (methods etc.). If you have a large number of classes in a Java application, an OOM can occur if the PermSize is too small.
- For the Max. Heap size, what would you recommend trying? Setting MaxPermSize to 1/4 of Xmx is suffient??
- I'd suggest getting some data first using the -XX:+PrintGCDetails flag. This flag breaks down GC information into nursery, old and perm spaces. That should indicate which space is running out of memory. Note that setting this flag has a performance impact.
As a ballpark figure, I'd start with:
-Xms512m -Xmx512m -XX:NewSize=128m -XX:MaxNewSize=128m -XX:PermSize=64m -XX:MaxPermSize=64m
Additional Links:
http://www.informit.com/guides/printerfriendly.asp?g=java&seqNum=99&rl=1
http://forum.java.sun.com/thread.jspa?tstart=0&forumID=27&threadID=343789&trange=15
http://forum.java.sun.com/thread.jspa?threadID=550279&messageID=2689390
http://forums.bea.com/bea/message.jspa?messageID=202464913&tstart=0
http://forums.oracle.com/forums/thread.jspa?messageID=453207

Related Posts:

Comments (3) Trackbacks (0)
  1. TEST CASE:

    1. Created a table test_13000_pages that contains 35×13000 records
    drop table test_13000_pages
    ;
    create table test_13000_pages
    (zahl number(10) ,daten varchar2(600))
    nologging
    ;
    begin

    for i in 1..13000
    loop
    for x in 1..35
    loop
    insert into test_13000_pages(zahl,daten) values(i, ‘aaaaaaaaaa’);
    end loop;
    end loop;
    commit;
    end
    ;

    2. created a simple report that displays 35 records per page
    select * from test_13000_pages

    3. executed the report in Builder by pressing Run Paper Layout Button
    Results: The report was executed sucessfully

    4. Generated the report in html format by File->generate to File -> HTML format
    Results: the html file was sucessfully generated

    5. generated the report in PDF format by File->generate to File -> PDF format
    Results: the builder crached without any error message

    6. Added the following JVM options in rwbuilder.conf file for the engine tag:
    jvmOptions=”-Xmx1024M -Xms1024M -Xss1024k”
    (Xss parameter is important)

    7. Started again builder and generated teh PDF file again .
    Results: the PDF file was sucessfuly generated.

  2. tried with following jvm memory options …
    …. but actually I’m having no idea what I’m doing here ….

    C:\orant_10gR2\BIN\rwbuilder.exe jvmoptions=”-Xmx1024M -XX:+PrintGCDetail -Xms1024M -Xss1024k”
    ==> 1. time: sucessful run (13000 pages complete)
    C:\orant_10gR2\BIN\rwbuilder.exe jvmoptions=”-Xmx1024M -XX:+PrintGCDetail -Xms1024M -Xss1024k”
    ==> 2. time: almost successful – file almost complete (around 12000 of 13000 pages)
    C:\orant_10gR2\BIN\rwbuilder.exe jvmoptions=”-Xmx1024M -XX:+PrintGCDetail -Xms1024M -Xss2024k”
    ==> PC gets slow…. almost successful – file almost complete (around 12000 of 13000 pages)
    C:\orant_10gR2\BIN\rwbuilder.exe jvmoptions=”-Xmx1024M -Xms1024M -Xss1024K”
    ==> almost successful – file almost complete (around 12000 of 13000 pages: filesize 26256kb)
    C:\orant_10gR2\BIN\rwbuilder.exe jvmoptions=”-Xmx1024M -Xms1024M -Xss1024K -XX:PermSize=64m -XX:MaxPermSize=64m”
    ==> almost successful – file almost complete (around 12000 of 13000 pages: filesize 26256kb)
    C:\orant_10gR2\BIN\rwbuilder.exe jvmoptions=”-Xmx1024M -Xms1024M -Xss1024K -XX:PermSize=64m -XX:MaxPermSize=64m -XX:NewSize=64m -XX:MaxNewSize=64m -XX:PermSize=64m -XX:MaxPermSize=64m”
    ==> not possible
    C:\orant_10gR2\BIN\rwbuilder.exe jvmoptions=”-Xmx1024M -XX:+PrintGCDetail -Xms1024M -Xss1024k”
    ==> 3. time: not successful – file not complete (around 4000 of 13000 pages)

  3. PROBLEM:
    When generating a report in PDF format that contains about 13 000 pages the Buider closes without any error message after genarating some number of pages. The report can be generated in HTML format with success.
    Expect that the 13 000 pages report should be generated in PDF format.

    CAUSE DETERMINATION:
    When creating a report in PDF format all pages for the report are created in memory then sent to the output. This leads to an increased need of stack size for processing.
    Similiaries to: Rep-56048 when running large report with desformat=spreadsheet or desformat=pdf

    SOLUTION:
    a) Use report DISTRIBUTION in order to split the report
    b) Use JVM options for the engine in order to increase engine stack size.
    If the report will be split using DISTRIBUTION the memory requrements for the engine will be a lot smaller and the maximum stack size that can be used by C code in a thread will not be reached.
    So just use the Oracle Report distribution in order to split the report output in smaller pieces! You’re all done …


Leave a comment

No trackbacks yet.