[
https://issues.apache.org/jira/browse/ABDERA-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918556#action_12918556
]
Abhishek Shadangi edited comment on ABDERA-267 at 10/6/10 12:20 PM:
--------------------------------------------------------------------
Thanks Andreas for giving Axiom developer's perspective :) Good to learn
further about the real cause. I realized the rationale behind immutability of
XMLInputFactory and XMLOutputFactory when I thought more about it. Thanks for
clarifying though.
I was about to upload the EXACT SAME patch here. This will work as there is
caching per configuration per classloader.
was (Author: shadangi):
Thanks Andreas for giving Axiom developer's perspective :) Good to learn
further about the real cause. I realized the rationale behind immutability of
XMLInputFactory and XMLOutputFactory when I thought more about it. Thanks for
clarifying though.
I was about to upload the EXACT SAME patch here :). However, there is ONE
problem with this fix. The StAXUtils allows creating either a standalone or per
classloader instances of immutable XMLInputFactory and XMLOutputFactory. So if
say Axis2 already initialized them, the StAXParserConfiguration and
StAXWriterConfiguration injected into the getXML*Factory method will never load
these properties. Moreover, the create APIs in StAXUtils are NOT public, so we
can't instantiate a new instance (perhaps a static instance) to load specific
properties regardless if there was a singleton or classloader instance already
instantiated.
I don't quite understand the rationale behind 2 things:
1. ONLY allowing singleton or per classloader instances of XMLInputFactory
and XMLOutputFactory
2. Uselessness of StAXParserConfiguration and StAXWriterConfiguration in
get APIs if an immutable instance has already been created
I personally think Axiom should provide further APIs to allow diverse usage of
XMLInput/OutputFactory. Right now it seems to constrain development. That way
Abdera can just create a new instance and reuse that instead of sharing it with
ALL other thirdparty libraries who are also using Axiom.
I would be glad to learn your thoughts and insights into these.
ps. I agree with your thoughts on Abdera trunk to work off of Axiom trunk. But
I also believe Axiom could warn before removing backwards compatibility; I
understand in some cases it's just not possible.
> 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
> Attachments: ABDERA-267.patch
>
>
> *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.
