Hi John,
None of Xerces' DOM implementations are thread-safe, even the non-deferred
ones. This is true even for read operations. In particular, the
implementation of the NodeList methods (i.e. item() and getLength()) are
not thread-safe. These methods do some internal writes to a cache which are
necessary for good performance. There's a longer explanation in the JIRA
issue you found.
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrgla...@ca.ibm.com
E-mail: mrgla...@apache.org
"Newman, John W" <newma...@d3onc.com> wrote on 06/07/2011 04:17:22 PM:
> All,
>
> My team has built a web application that has a few components that
> rely heavily on the xerces DOM implementation. Unfortunately a lot
> of this was developed before we even learned that the node
> implementations are deliberately not thread safe. =) I?ve added a
> few sync blocks where appropriate (I think), and everything is
> functioning ok except for two remaining issues.
>
> 1) Under very high load, an element will somehow lose nearly
> all of its children.
> <root>
> <ch0 />
> <ch0 />
> <ch0 />
> <ch1 />
> <ch1 />
> <ch2><ch2.1 /></ch2>
> <ch3><ch3.1><ch3.2 /></ch3.1></ch3>
> ?. Rather large document, many levels of nesting
> </root>
>
> That will sit there and work fine for a few days, until something
> (?) happens and most of the children will disappear . I cannot
> isolate this problem at all, it has been very difficult to track
> anything down so I?m asking for help. There are no exceptions in
> the log or anything otherwise to indicate that something bad is
> happening. One day I saw
>
> <root>
> <ch0 />
> <ch0 />
> </root>
>
> And then a few days later
>
> <root>
> <ch0 />
> <ch0 />
> <ch0 />
> <ch1 />
> </root>
>
> The fact that there doesn?t seem to be any pattern to which children
> stay vs. which disappear, and only under higher load has me
> suspecting thread safety. In general it seems like the smaller
> elements at the top are more likely to hang around, but again
> there?s no real pattern. We are not doing any modification on these
> nodes, in fact I want to make them read only. I?m debating on
> casting the org.w3c.Node to org.apache.xerces.dom.NodeImpl and
> calling setReadOnly(true, true) on it to freeze it ? but the
> javadoc says I probably shouldn?t need that method? If I did that,
> I?d at least get a stack trace when whatever it is decides to modify
> it. Does that sound like a good approach? Is there anything
> obvious that would cause this problem, e.g. has anyone ran into this
> before? Am I missing a sync? I?m about stumped.
>
> 2) Also under high load, I occasionally get this stack trace
> (this is not the cause of or symptom of item 1, it is a separate
> issue occurring at separate times)
>
> java.lang.NullPointerException:
> (no message)
> at org.apache.xerces.dom.ParentNode.nodeListItem(Unknown Source)
> at org.apache.xerces.dom.ParentNode.item(Unknown Source)
> at freemarker.ext.dom.NodeListModel.<init>(NodeListModel.java:89)
> at freemarker.ext.dom.NodeModel.getChildNodes(NodeModel.java:302)
> at freemarker.ext.dom.ElementModel.get(ElementModel.java:124)
> at freemarker.core.Dot._getAsTemplateModel(Dot.java:76)
>
> Again I?m suspecting thread safety and a missing sync. Just
> refreshing the page works ok. I raised the issue with freemarker
> since it?s only their stack frames calling the DOM, so I figured the
> burden falls on them to sync. But they passed the puck back to me
> and said ?we do not guarantee thread safety if your data model is
> not thread safe to begin with.? They?re not going to go and add
> sync blocks all over their code due to an implementation artifact of
> your library, and I would agree with that. Really the lack of
> thread safety even for reads is a pretty poor fit for a web
> application... How do I fix this problem, in general is there a way
> to make this library more thread safe? The best suggestion I have
> for that stack trace so far is to use CGLib to proxy the element and
> inject sync blocks where they should be. Ugh? https://
> issues.apache.org/jira/browse/XERCESJ-727 is relevant here
>
> What about calling documentBuilderFactory.setFeature("http://
> apache.org/xml/features/dom/defer-node-expansion", false); to turn
> off lazy parsing? Does that guarantee thread safety since
> everything is already parsed into ram and it?s just read only?
>
>
> Any input is very much appreciated, these issues are affecting
production. K
>
> Thanks,
> John
