[
https://issues.apache.org/jira/browse/ABDERA-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918491#action_12918491
]
Andreas Veithen commented on ABDERA-267:
----------------------------------------
Abhishek's analysis is correct, and I would like to add some more explanations
(wearing my Axiom developer hat):
* Some background information about the isSetPrefixBeforeStartElement thing can
be found in [1]. It is actually not Axiom that got it wrong, but a particular
version of a particular StAX implementation. In Axiom 1.2.9, we isolated that
code into what we call a StAX dialect so that it is only ever triggered when
that particular StAX implementation is used.
* On the other hand, the performance issue related to
isSetPrefixBeforeStartElement was already addressed in 1.2.8 (see
WSCOMMONS-325). So upgrading to that version instead of 1.2.9 may provide a
quick fix for the issue.
* In Axiom 1.2.9, the factories returned by StAXUtils are indeed immutable. The
reason is that these factories are cached and therefore shared with other
frameworks using Axiom. E.g. if Abdera and Axis2 are used in the same
application, they would get the same factory instances from Axiom. Therefore we
can't allow modifications of these factory instances, because this has the
potential of causing subtle issues. In 1.2.9, we also introduced new features
that allow to customize the factories in a controlled way, but for
XMLOutputFactory instances, this is only implemented in the current trunk.
* Since Abdera extends Axiom implementation classes (namely the LLOM
implementation), it is indeed strongly coupled and therefore very sensitive to
changes in Axiom. Probably the best way to avoid these issues is to have the
Abdera trunk depend on the Axiom trunk so that incompatibilities are detected
early by the Abdera build in Hudson.
I will see what needs to be done in the Abdera and Axiom code to make them
again play nicely together.
[1] http://markmail.org/thread/37y3qjcfucb6756o
> Major performance issue with Abdera (underlying Axiom) object model while
> writing Atom DOM to XmlStreamWriter
> -------------------------------------------------------------------------------------------------------------
>
> Key: ABDERA-267
> URL: https://issues.apache.org/jira/browse/ABDERA-267
> Project: Abdera
> Issue Type: Improvement
> Affects Versions: 1.1
> Environment: N/A
> Reporter: Abhishek Shadangi
>
> *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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
