Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.1
-
None
-
N/A
Description
Background:
Abdera object model (OM) is based off of Axiom OM. In FOMDocument class (which extends Axiom's OMDocumentImpl), method toWrite(java.io.Writer) makes a call to this.internalSerialize(javax.xml.stream.XmlStreamWriter). After this point Abdera delegate the XML stream writing to Axiom.
Issue:
Axiom 1.2.7, has a serious performance issue if one is using likes of woodstox's implementation (com.ctc.wstx.sw.SimpleNsStreamWriter - http://woodstox.codehaus.org/3.2.9/javadoc/index.html ), which I believe is the default writer used by Axiom.
The internalSerialize call eventually makes it to org.apache.axiom.om.impl.util.OMSerializerUtil.serializeStartpart(OMElement element, String localName, XMLStreamWriter writer). Now, here starts the major performance hog. This makes a call to isSetPrefixBeforeStartElement(XmlStreamWriter), which handles one of the MOST controversial part of the XmlStreamWriter spec - http://download.oracle.com/javase/6/docs/api/javax/xml/stream/XMLStreamWriter.html.
They fairly recognized this in the javadocs for OMSerializerUtil.isSetPrefixBeforeStartElement in Axiom version 1.2.7. But they got the implementation all wrong. The implementation looks for the property javax.xml.stream.XMLStreamWriter.isSetPrefixBeforeStartElement in the writer, which throws an IllegalArgumentException if this property is not found, which IS NOT FOUND. The implementation then catches this exception and returns false. This happens for EVERY single element written to output stream. This exception handling is way too much expensive and when it happens per element in XML per request, it takes MOST part of the processing time every request. More on this specific property - http://publib.boulder.ibm.com/infocenter/realtime/v2r0/index.jsp?topic=/com.ibm.rt.doc.20/user/xml/xlxpj_reference.html.
Since Abdera is meant for Atom feed, when there are concurrent requests the overall latency per request increases more than linearly and after a while it becomes unusable for high load.
Axiom realized this flaw in their logic and fixed it in 1.2.9. Hence, Abdera SHOULD consider upgrading it's code to use Axiom 1.2.9 instead of 1.2.7, and this performance issue will be gone. For our use, I explicitly made this change to use the new Axiom library but there are other dependencies which is preventing me to make the upgrade that easily.
Most importantly, after upgrading the JAR, I get the following exception.:
Caused by: java.lang.IllegalStateException: This factory is immutable
at org.apache.axiom.util.stax.wrapper.ImmutableXMLOutputFactory.setProperty(ImmutableXMLOutputFactory.java:39)
at org.apache.abdera.parser.stax.StaxStreamWriter.createXMLStreamWriter(StaxStreamWriter.java:106)
at org.apache.abdera.parser.stax.StaxStreamWriter.setOutputStream(StaxStreamWriter.java:113)
This is because javax.xml.stream.XmlOutputFactory and javax.xml.stream.XmlInputFactory, that Axiom 1.2.9 creates, are now immutable and Abdera code is trying to set some javax.xml.stream.* properties in them. To fix this, I updated StaxStreamWriter.createXMLStreamWriter and FOMParser.getXMLInputFactory to NOT set any property. For our purposes this seems to work fine so far, but perhaps needs a bit more research to make the real fix.
Action items:
1. Upgrade to Axiom 1.2.9
2. Fix places where Abdera (esp. parser module) is trying to modify the immutable XmlInputFactory and XmlOutputFactory as returned by Axiom.
Attachments
Attachments
Issue Links
- is related to
-
AXIOM-58 org.apache.axiom.om.impl.util.OMSerializerUtil.isSetPrefixBeforeStartElement() doing property lookup on every invocation - performance problem
-
- Closed
-