>"What exactly is "high load" in your case? Is it number of users using your >applications, number of threads sharing your objects or what?"
~100 users at the same time, a percentage of which are reading the same node and slicing through 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." Well, insufficient design would be using this non thread-safe library in an application that is constantly multithreaded. =) My application is not modifying the element. I don't know what else to say besides: sql proc returns xml. Xml is parsed into DeferredElementImpl. Element is stored in ram for access. Pages read element to display children. Users click through elements children and ultimately select a leaf node which gets written to table. When I have a number of users reading the element in a certain ways at certain times, the children just disappear. We are using jaxb generated classes for most of our types that are xml output from the database. That all works fine. But for this one particular element type, the data model of it is 'too dynamic', in that they change their mind every 6 weeks on what it should look like. I can't put out new application builds every 6 weeks to accommodate this and maintain different versions of jaxb objects within, so dynamic xpaths through the DOM is the only good fit. I'm not so worried about #2 because that isn't very disruptive and it should be an easy fix, just a bit crazy to use cglib for this. #1 is a disruptive problem that needs hotfixed as soon as I can. What could cause the children to disappear? The developers who know the library should be able to answer this. Is there any way a child would disappear besides an explicit call to removeChild() ? Thanks for all the responses. -----Original Message----- From: Mukul Gandhi [mailto:muk...@apache.org] Sent: Wednesday, June 08, 2011 12:03 AM To: j-users@xerces.apache.org Subject: Re: DOM thread safety issues & disapearring children On Wed, Jun 8, 2011 at 1:47 AM, Newman, John W <newma...@d3onc.com> wrote: > 1) Under very high load > an element will somehow lose nearly all of its children. > 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) 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. Unfortunately none of those are _my_ classes. They are freemarker's classes. So I can't go in there and put synchronized(node){} everywhere it needs to be. I think they should, but they say you should since that's where the volatility comes from or I'll need to proxy it. Ick. It does not show up in a debug session, I need to write the exact test for this scenario but I can't figure it out. Either way I know where the sync needs to be added, I just can't do anything about it (short of some wacky proxy solution) -- Regards, Mukul Gandhi --------------------------------------------------------------------- To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
