Hi All, Joining this thread on Vinh's recommendation.
This issue I believe stems from both https://issues.apache.org/jira/browse/XERCESJ-911 where large amounts of Muse use this functionality. Regarding the ThreadLocal solution it doesn't work to cache documents themeselves. The sdk is very clear that only DocumentFactory.getInstance is thread safe. You can use ThreadLocal with DocumentBuilders however. (new DocumentBuilders is quite expensive, but new documents are much cheaper) The solution below (combined with TLS DocumentBuilders) should resolve the issue with both WRONG_DOCUMENTs and the 911 issue from xerces. I read in the rest of the thread that Vinh had a simple test case with multiple threads. I'm happy to do a quick refactor in the code to put these two approaches into the code base, if you could send me the test case Vinh, I'll get started on it tomorrow. NB whilst this "should work" it is still against the spirit of xerces which is share nothing. I'd also note that due to the nodecache optimisation within Xerces, using NodeLists its just not possible to be thread safe even for reads. copied from muse-user: Hi, >From what I could work out, from within the list comments and the code, the state is stored in the Document itself, and as cloneNode uses Object.clone and then sets the doc it won't work. Using importNode helps a little (as it uses getFirstChild()/getNextSibling()), but it just puts the problem to a later stage. getAllElements just does the same, calls getChildNodes and then forces the cache to be used. Deleting the cache just stops the null for the parent, it doesn't stop incorrect nodes being returned or race conditions with other nulls. The simple thing is to stop using getChildNodes, from what I can see in the code there isn't a need for it. The only place I've seen that doesn't require all of the nodes anyway is in EndpointReference's getNumberOfParameters, but that behaviour can be safely cached (its not used directly in the project anyway). Looking further at the use cases in Muse only the IsolationLayer (because of the DeferredImpl) needs to call hasChildNodes() on the document node, for it to force that synchronizeChildren be called (its cached from then on in each node). Then every other piece of code can simply pointer chase with the getFirstChild()/getNextSibling() approach. No synchronization required. re using other jaxp's, the DOM itself makes no statement about even read thread safety. All of the jaxp impls suffer some form of threading problem. Considering all of the problems with fighting against namespace problems (much worse IMO) it makes sense to stick with the devil you know :-<. Again for most of the xerces releases using the getFirstChild()/getNextSibling() is a seamless dropin for the getChildNodes problem. Its a shame that the xerces guys are very much against any form of thread safety (except application enforced). Going with the standard approach the only safe thing is to always serialize to objects / keep the strings around, which would overly complicate the code. I'm willing to give it a try and send you patched libs to try out (I don't have a test case for this yet) if its quick to reproduce, just let me know. If it works out I can raise a jira with the patches. cheers, Chris --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
