Fw: Travel Assistance applications now open for ApacheCon NA 2011
Forwarding on behalf of the ASF's Travel Assistance Committee. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org "Gavin McDonald" wrote on 06/06/2011 04:03:24 AM: > The Apache Software Foundation (ASF)'s Travel Assistance Committee (TAC) is > now accepting applications for ApacheCon North America 2011, 7-11 November > in Vancouver BC, Canada. > > The TAC is seeking individuals from the Apache community at-large --users, > developers, educators, students, Committers, and Members-- who would like to > attend ApacheCon, but need some financial support in order to be able to get > there. There are limited places available, and all applicants will be scored > on their individual merit. > > Financial assistance is available to cover flights/trains, accommodation and > entrance fees either in part or in full, depending on circumstances. > However, the support available for those attending only the BarCamp (7-8 > November) is less than that for those attending the entire event (Conference > + BarCamp 7-11 November). The Travel Assistance Committee aims to support > all official ASF events, including cross-project activities; as such, it may > be prudent for those in Asia and Europe to wait for an event geographically > closer to them. > > More information can be found at http://www.apache.org/travel/index.html > including a link to the online application and detailed instructions for > submitting. > > Applications will close on 8 July 2011 at 22:00 BST (UTC/GMT +1). > > We wish good luck to all those who will apply, and thank you in advance for > tweeting, blogging, and otherwise spreading the word. > > Regards, > The Travel Assistance Committee
DOM thread safety issues & disapearring children
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.
Rather large document, many levels of nesting
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
And then a few days later
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.(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. :|
Thanks,
John
Re: DOM thread safety issues & disapearring children
On Wed, Jun 8, 2011 at 1:47 AM, Newman, John W wrote: > 1) Under very high load What exactly is "high load" in your case? Is it number of users using your applications, number of threads sharing your objects or what? > an element will somehow lose nearly all of its children. This may be due to insufficient design within your application. You need to tell more about your application design and give us more specifics, for anyone to reason about the failures. > 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.(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) The null pointer originates from your framework/application classes (Dot.java -> ElementModel.java & so on). This may be an application issue. You may run a debug session to see, which object along this stack trace is null and on what data it is dependent on. -- Regards, Mukul Gandhi - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: DOM thread safety issues & disapearring children
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" 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.
>
>
>
>
>
>
>
>
> ?. Rather large document, many levels of nesting
>
>
> 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
>
>
>
>
>
>
> And then a few days later
>
>
>
>
>
>
>
>
> 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.(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
Re: DOM thread safety issues & disapearring children
Hi Mukul, Mukul Gandhi wrote on 06/08/2011 12:02:59 AM: > > 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.(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) > > The null pointer originates from your framework/application classes > (Dot.java -> ElementModel.java & so on). This may be an application > issue. You may run a debug session to see, which object along this > stack trace is null and on what data it is dependent on. No, I'm 99.99% sure this is a threading issue. ParentNode.nodeListItem() is one of several places you can get a NullPointerException if you don't synchronize. There's really no other way to get an NPE there. The application is merely passing in an int to the item() method. That either returns a Node or null if the index isn't valid. > -- > Regards, > Mukul Gandhi > > - > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org
Re: DOM thread safety issues & disapearring children
On Wed, Jun 8, 2011 at 9:48 AM, Michael Glavassevich wrote: > No, I'm 99.99% sure this is a threading issue. ParentNode.nodeListItem() is > one of several places you can get a NullPointerException if you don't > synchronize. > > There's really no other way to get an NPE there. The application is merely > passing in an int to the item() method. That either returns a Node or null > if the index isn't valid. Thanks, Michael for the thoughts. -- Regards, Mukul Gandhi - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
