Search code examples
jaxbgarbage-collectionweblogiceclipselinkdocx4j

JAXB peformance issue with WebLogic 12.1.2's EclipseLink.jar


When generating a several hundred page docx document file w/ embedded images using docx4j on WebLogic 12.1.2, the performance is about 5 times slower than the same operation on WebLogic 12.1.3 running on the same virtual machine w/ the same JVM configuration -- about 20 minutes on 12.1.2 vs. 4 minutes on 12.1.3.

Ran top to get CPU and memory stats and jstat -gc to get garbage collection stats. While generating the doc, the CPU pegs at 100% on 12.1.2 vs. 15% on 12.1.3. The eden heap usage grows rapidly on 12.1.2 and so gets garbage collected frequently vs. growing quite slowly on 12.1.3. Ran jstack several times while the operation is running to view the thread stack. Nine times out of ten, on 12.1.2 the stack shows that docx4j is calling EclipseLink's JAXB and that JAXB is class loading -- a lot of class loading that takes a lot of CPU time (maybe related to: Do I have a JAXB classloader leak but don't have direct control over docx4j).

The issue has been isolated down to the eclipselink.jar, which contains the JAXB libraries, insofar as when the eclipselink.jar from the WebLogic 12.1.3 shared libraries (EclipseLink v2.5.2) is copied over the WebLogic 12.1.2 version (EclipseLink v2.4.2) and then the docx generation run on WebLogic 12.1.2 the performance is good, just as on 12.1.3.

Question:

Can the performance of WebLogic 12.1.2 w/ EclipseLink 2.4.2 be improved without swapping out libraries? For instance, are there any JVM options that may help?

Current JVM options:

-Xms4096m -server -Xmx4096m -XX:MaxPermSize=512m -XX:MaxGCPauseMillis=69 -XX:ParallelGCThreads=8 -XX:ThreadStackSize=2048 -XX:SurvivorRatio=32 -XX:+DisableExplicitGC -XX:+AggressiveHeap -Xloggc:/var/tmp/gc.log -Djava.awt.headless=true


Solution

  • You could try creating a WebLogic Shared Library containing EclipseLink 2.5.2 and reference that from your application deployed on WebLogic 12.1.2: